cyliax@ecn.purdue.edu (Ingo Cyliax) (11/06/90)
I have been thinking of a way to implement a paging Minix system that would not alter much in the MM process. Of course this would be a paging system and would require paging hardware as well as a MMU. Why not just implement a large virtual memory space for Minix and handle paging at very low level, in the kernel tasks for example. This way MM would just think it had a very large chunk of memory to work with. as it started to allocate memory chunks and the processes that started using them started page faulting the page task would page them in from disk, and page unused pages out to disk. The page task could tell the system task certain processes have to be suspended while their missing pages where paged in. Of course there has to be a way to protect the pages in the kernel tasks, as well as locking in pages during I/O. With this aproach there wouldn't be a need to change MM or FS. The changes would be confined to an additional task in the kernel and some minor changes in the system task, and possibly the drivers. All program would still run without change, except that you can chmem them as big as you need. Of course this doesn't help people that don't have architectures that do not support paging, but it would be very transparent. Unless I'm missing something. Comments ? -ingo -- /* Ingo Cyliax ECN, Electrical Engineering Bldg. * * cyliax@ecn.purdue.edu Purdue University, W. Lafayette,IN 47907 * * ing@cc.purdue.edu Work: (317) 494-9523 * * cyliax@pur-ee.UUCP Home: (317) 474-0031 */
ast@cs.vu.nl (Andy Tanenbaum) (11/07/90)
In article <1990Nov6.071459@ecn.purdue.edu> cyliax@ecn.purdue.edu (Ingo Cyliax) writes: > >Why not just implement a large virtual memory space for Minix and handle >paging at very low level, in the kernel tasks for example. This way MM Not a bad idea. It might work. I haven't really looked at it carefully though. Andy Tanenbaum (ast@cs.vu.nl)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (11/08/90)
To contribute to the paging discussion: Remember that paging must not mean that parts of the virtual memory are swapped to a disk. Paging may simply mean that you can allocate memory to processes in a flexible way by translating virtual to physical addresses by means of pages, thus solving the chmem problem. If 68000, 68010, 68020, 8088, 8086, 80286 are gone, AST will not be against THAT. C.v.W.
mh2f+@andrew.cmu.edu (Mark Hahn) (11/08/90)
Andy Tanenbaum (ast@cs.vu.nl) writes: >>Why not just implement a large virtual memory space for Minix and >>handle paging at very low level, in the kernel tasks for example. > >Not a bad idea. It might work. I haven't really looked at it carefully >though. I hate to ask a flippant question, but: "why not?" Surely the Minix community is more than just students taking their first OS course. For myself, I'm considering trying Minix, but am also discouraged by this archaic lack virtual memory. Note also that more advanced OS courses might use a future Minix to study user-level VM primitives and the ideas like those in Mach. regards, Mark
culberts@hpcc01.HP.COM (Bruce Culbertson) (11/09/90)
> I have been thinking of a way to implement a paging Minix system that > would not alter much in the MM process... > > Why not just implement a large virtual memory space for Minix and handle > paging at very low level, in the kernel tasks for example. My Minix port to the National 32000 implements some aspects of VM and does it in approximately the manner you have described. I posted a fairly detailed description of the port when I finished it in June 1989. The system task in my Minix port provides memory management services to MM. MM can request that a memory space be created, freed or enlarged (for the break system call). MM does not need to know how the system task implements these services. For example, the system task could use the allocation algorithm which is currently used in standard Minix. However, I chose to use the 32000's paging MMU to assemble user memory spaces from noncontiguous pages of physical memory. Code and data/bss are loaded at the low end of the user's virtual address space and the stack is placed at the top. Break calls and page faults due to stack growth cause pages to be added to user spaces. User spaces can grow until physical memory is exhausted. Chmem is not used. MM can also request the system task to fork a process. I have implemented copy-on-write forking. This creates the illusion that a memory space has been copied when, in fact, only a new page table is created. Forked processes share pages until a process tries to write a shared page. At that time, a page fault causes the shared page to be duplicated, providing the writer with a private copy. Because of copy-on-write forking, it is possible for the sum of the virtual spaces on my computer to exceed the size of physical memory. However, pages are never swapped to a disk. Paging to disk would be a very nice addition to my Minix port. A very desirable virtual memory feature is the ability to "fault in" a process from its a.out file. This allows a process to start running as soon as its first text page is loaded. This is somewhat difficult to implement efficiently in Minix because the fault handler, which should be low level and fast, needs to know the organization of the file system. My solution to this problem, which I have not implemented, is to have FS, as part of its exec call, assemble an array of disk block numbers for the a.out file blocks. Creating this array would be considerably faster than actually loading the blocks. Once the array was passed to the system task, the a.out file could be faulted in without consulting FS. Bruce Culbertson culberts@hplabs.hp.com
zseelunnon@qut.edu.au (11/10/90)
In article <35678@nigel.ee.udel.edu>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: > To contribute to the paging discussion: > > Remember that paging must not mean that parts of the virtual memory are > swapped to a disk. > Paging may simply mean that you can allocate memory to processes in a > flexible way by translating virtual to physical addresses > by means of pages, thus solving the chmem problem. > > If 68000, 68010, 68020, 8088, 8086, 80286 are gone, AST will not be > against THAT. > Hmm, I have been thinking, for the 68K it would be possible to page to disk memory belonging to idle processes on a task switch leaving all available memory for the running application, thus a 68K minix would be able to run several processes larger than the physical memory size. If two processes own the same block of memory (that is an in-core process and the next process ) then the whole or part of the in core process could be swapped out to make room this could also happen if malloc was called. The only real problem here is that once the processes own the same block , swapping WILL occur on invocation of each of the processes until one frees the common memory block (as it is not possible to move data around :-( ). > C.v.W.
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (11/16/90)
The biggest problem of today's minix is Memory Management. Besides, in totay's MINIX, a malloc() will never cause a swapping because the MAXIMUM memory is allocated to a process on exec'ing it by MM, no matter if this process uses the memory or not. C.v.W.