paradis@crater.zk3.dec.com (Jim Paradis) (11/29/90)
I'm currently running MINIX 1.5.10 with Bruce Evans' 32-bit patches. I'm in the process of implementing demand-paged virtual memory, and I'm running into a problem. Here's a summary of the situation: - For simplicity's sake, I have a single page table for the entire system (much as Bruce does now). This way, MM and friends can operate as they do now, assuming a single system-wide linear memory address space. Protection et al is handled by the segmentation mechanism. - I have a task called PAGER, which handles pageins and pageouts. - When MM allocates a range of memory, it asks the kernel to set up a range of PTEs as demand-zero pages. These aren't backed with physical memory until they are actually referenced, at which time the PAGER allocates a page from the free pool, maps it in, and zeros it. - When I take a page fault, the page fault handler finds the faulting virtual (linear) address, fires off a message to the PAGER, and waits for a reply to come back before continuing. At least that's how it's SUPPOSED to happen. I've been tearing my hair out for the past week actually trying to MAKE it happen. I don't have paging to/from disk implemented yet, but I am taking page faults to resolve demand-zero pages. Things seem to work just fine UNTIL a process takes a page fault while in the middle of a system call. What happens then is that for some reason the pager doesn't get scheduled and that either the faulting process or the IDLE task gets re-scheduled. One note on my page fault handler: I modeled it after the SYSCALL handler such that it saves the process registers on the stack, switches DS and SS to the kernel data segment, gets the fault address, and calls the C handler routine. I've tried two different mechanisms for jolting the pager task: one using the interrupt() routine, and one using lock_mini_send() to send a message. Both work just fine when it's a TASK taking the page fault, but both fail when it's a user process inside a syscall. So: is there anyone out there with any insight into the MINIX scheduler who might be able to give me some suggestions? At this point I'm stuck... I've tried experimenting with this and that, all to no avail. I've been glued to my computer during every free moment I have, determined to track this one down... my wife and cats are starting not to recognize me anymore 8-) Oh, one other question: Is there any reason (other than the implementation of brk() and a few other things) why DS and SS can't be in separate segments? It would be really nice to be able to make two separate, expandable segments and not have to bother with "chmem" anymore... Thanks, Jim Paradis, working at but not employed by DEC. (603)881-1221 paradis@decvax.dec.com "All I got was a rock!"
hp@vmars.tuwien.ac.at (Peter Holzer) (11/29/90)
paradis@crater.zk3.dec.com (Jim Paradis) writes: >Oh, one other question: Is there any reason (other than the >implementation of brk() and a few other things) why DS and SS can't >be in separate segments? It would be really nice to be able to make >two separate, expandable segments and not have to bother with "chmem" >anymore... The only reason I can think of is that you would not want to have far pointers. A flat address space is easier to handle both at compile and run time as compilers usually have trouble with pointers that are split over two registers and reloading segment registers rather expensive. On the other hand, shared libraries are much easier to implement if you have a segmented address space. The chmem problem will be almost non-existent once we have paging. Just chmem all programs to more than your physical memory size (RAM + page/swap-space) and heap and stack can never collide. Since you are mapping pages only when they are referenced they will even need less space than they do now. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (11/30/90)
SS and DS must be the same segment..... since a called subroutine with a pointer argument does not know if it points to automatic (SS) or static (DS) data of the caller. So, stack&data must share the ADDRESS SPACE, but, they can be separated by a big gap, allowing each range to grow. C.v.W.
paradis@crater.zk3.dec.com (Jim Paradis) (11/30/90)
In article <37646@nigel.ee.udel.edu> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >So, stack&data must share the ADDRESS SPACE, but, they can be separated >by a big gap, allowing each range to grow. Ah yes... this has been pointed out to me several times in e-mail as well Anybody got a towel so I can wipe the egg off my face? 8-). Believe it or not, I hack UNIX kernels for a living, and VM is one of my specialties... I know all about putting text+data+bss+heap at the bottom of the address space and putting the stack at the top. Thing is, most UNIces allocate a whole flat virtual address space (i.e. 4Gb) for EACH process, so this is never a problem. In order to keep my MINIX VM implementation simple (and to make the fewest changes to MM), I decided to run the whole system in a SINGLE virtual space. This makes virtual address space SOMEWHAT of a scarcer resource (instead of 4Gb/process, I've got to make all the processes divvy up the 4Gb among themselves). I suppose I could just give each process, say, 16Mb (max. physical memory supported by most 386 boxes). While that limits me to "only" 256 processes per system, that probably won't be TOO much of a limitation for a 386-box class machine 8-). (actually, what I planned to do was to have two classes of processes: big and normal. A normal process runs like they do today: it's chmem'd to a certain value, and it gets that much space when it execs. A big process is chmem'ed to zero, and when exec detects this is allocates one of these 16Mb hunks for it instead. This way, small processes with well-bounded VM behavior don't need to chew up big amounts of VM space...) As for why I might consider 16Mb to be a tight virtual address space... remember: I want to run GCC and Gnu Emacs 8-) 8-) 8-) Jim Paradis, working at but not employed by DEC. (603)881-1221 paradis@decvax.dec.com "All I got was a rock!"