huilin@hpindda.HP.COM (Hui Lin Lim) (12/31/88)
Has anyone considered putting the RAM disk into extended memory when MINIX is run on 386 systems? I'm new to MINIX having just bought the book and software (v1.2) but haven't seen any discussion about this so far. If anyone has already done this I'd certainly appreciate hearing from you. Thanks. Hui Lin
jds@mimsy.UUCP (James da Silva) (01/01/89)
In article <3580016@hpindda.HP.COM> huilin@hpindda.HP.COM (Hui Lin Lim) writes: >Has anyone considered putting the RAM disk into extended memory >when MINIX is run on 386 systems? I'm new to MINIX having just >bought the book and software (v1.2) but haven't seen any >discussion about this so far. This feature was added shortly after 1.2 was released. Minix 1.3 will put the RAM disk into extended memory if the root disk image is greater than 255K bytes. Jaime ........................................................................... : domain: jds@mimsy.umd.edu James da Silva : path: uunet!mimsy!jds
ast@cs.vu.nl (Andy Tanenbaum) (01/04/89)
In article <3580016@hpindda.HP.COM> huilin@hpindda.HP.COM (Hui Lin Lim) writes: >Has anyone considered putting the RAM disk into extended memory >when MINIX is run on 386 systems? I'm new to MINIX having just >bought the book and software (v1.2) but haven't seen any >discussion about this so far. In 1.3, the root file system can be put in extended memory on a 286. I don't actually know how that works on a 386. The extended memory is driven by a routine in klib88.s, so if 386 extended memory has to be accessed differently, that routine will have to be changed. Has anyone used extended memory on a 386? Andy Tanenbaum (ast@cs.vu.nl)
huilin@hpindda.HP.COM (Hui Lin Lim) (01/05/89)
>ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <3580016@hpindda.HP.COM> huilin@hpindda.HP.COM (Hui Lin Lim) writes: >>Has anyone considered putting the RAM disk into extended memory >>when MINIX is run on 386 systems? I'm new to MINIX having just >>bought the book and software (v1.2) but haven't seen any >>discussion about this so far. > >In 1.3, the root file system can be put in extended memory on a 286. >I don't actually know how that works on a 386. The extended memory is >driven by a routine in klib88.s, so if 386 extended memory has to be >accessed differently, that routine will have to be changed. Has anyone >used extended memory on a 386? I believe that the 286 version of software should work but a version written specifically for the 386 should be much more efficient since the 386 does not have to reset when switching from protected to real mode. Please note that I am speaking NOT from experience but just from what I know of the 386. (I'm also assuming that MINIX normally runs in the real mode on 286/386 systems. Hui Lin Lim
evans@ditsyda.oz (Bruce Evans) (01/11/89)
In article <3580017@hpindda.HP.COM> huilin@hpindda.HP.COM (Hui Lin Lim) writes: >I believe that the 286 version of software should work but a >version written specifically for the 386 should be much more >efficient since the 386 does not have to reset when switching >from protected to real mode. Please note that I am speaking NOT My 386 protected mode port (to be posted in a few weeks) of course avoids the switching. The routine em_xfer() to handle extended memory is no longer necessary - the RAM disk just uses phys_copy(). The efficiency gain is not very important: i/o times for 10M done with one 128K file in 8 blocks of 16 repeated 80 times (cache should be irrelevant): protected unprotected read: 13.1 sec 22.4 sec write: 13.3 sec 22.6 sec i.e. about 777000 bytes/sec protected and 464000 unprotected. Compared with the processor limitation of 20M/sec (at 20MHz) and the RAM limitation of 9.5M/sec (on my machine), these times are uniformly awful, so time would be better spent improving FS. DOS gets around 4M/sec on this test. The main reason FS is slow is it breaks up large blocks into 1K blocks for the drivers, when it would be better to do the opposite. Assuming the difference in the times is from switching overhead (an overestimate), and 10K blocks to give the 10M (an underestimate), the switching overhead is 0.93 millisec. This is more important, since interrupts are disabled for this time plus the copy time of 0.1 millisec (more on AT's) so serial interrupts will be lost around 9600 baud. There were CPU bugs which killed my original version of the protected mode phys_copy(). The string instructions didn't work right across 64K boundaries, using a 16 bit code segment with adress size prefixes to get at a 32 bit data segment Using a 32 bit code segment sidestepped the bugs. Does anyone know about the official 386 bug list or if I can get I free new CPU? (Mail only on this.) -- Bruce Evans evans@ditsyda.oz.au D