Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!herald.usask.ca!ccu.umanitoba.ca!bonnie.concordia.ca!uunet!email!vmars!hp
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Newsgroups: comp.os.minix
Subject: Re: Virtual addresses
Message-ID: <1991May17.130611.5430@email.tuwien.ac.at>
Date: 17 May 91 13:06:11 GMT
References: <53697@nigel.ee.udel.edu> <1991May16.171429.438@email.tuwien.ac.at> <1991May16.210048.18717@menudo.uh.edu>
Sender: news@email.tuwien.ac.at
Distribution: "world"
Organization: Technical University of Vienna, Dept. for Realtime Systems
Lines: 61
Nntp-Posting-Host: nowhere.vmars.tuwien.ac.at

st12a@menudo.uh.edu (richard henderson~) writes:

>In article <1991May16.171429.438@email.tuwien.ac.at>
>	hp@vmars.tuwien.ac.at (Peter Holzer) writes:

>> [proposed merging kernel and MM]

>It does violate the ring protection scheme, however, things might just
>run a bit faster if the system task and the mm were merged; there would
>be no waiting for the task switch.

This is true. It is cleaner if user processes never communicate
directly with the kernel but only with servers. That reminds me, that I
have not yet discovered any scheme that prevents user processes from
sending messages to kernel tasks except code in these tasks like:
if (sender != FS && sender != MM) panic ();
That would make a great way to reboot without pressing ctrl-alt-del :-)
(I haven't tried it yet, though).


>>>One thing I'd like is the ability for processes to expand so
>>>that when a process grows past it's chmem'd limit, it just gets
>>>bigger. This could be done with swapping.
>>
>>This won't work because the Stack grows downward from the chmem'ed
>>address. When stack and heap meet, you cannot just expand your
>>data/stack segment and copy the stack to its new location without
>>invalidating all pointers pointing into the stack area (e.g. argv).

>Not true.  Simply put the stack at the "top" of addressable memory for
>each process and leave the memory between _brk and sp unmapped.  That
>way, when the stack grows, a page fault is generated, and the os tacks
>on more memory.  When brk(2) is called, more memory is tacked on from
>the bottom end.

You have to add paging to do that (at least on the 386, I do not know
about 68k MMUs) and Andy doesn't like paging at all
(As far as I know even Amoeba doesn't page), so we have little chance
to add this to standard minix. My proposal is a small change that could
easily be added to Minix and works with or without MMU. Of course it is
not quite as flexible but much simpler. Even with paging I would stay
with the current scheme of chmem'ing programs (only chmem every program
to 16MB or so) because it gives the kernel simultaneous access to all
processes. Minix does copy lots of data between user processes and the
servers so I think barring the kernel from seeing both of them is not a
good idea (Of course you could reserve 1GB for a user proc., 1 GB for a
server, and 1 for the kernel tasks and one for the interrupt
multiplexer, but I think this is ugly).

On a related note why, is shadowing used in 68k minix? You could
simulate an MMU by reserving one register for a base address and do all
addressing relative to this register. Has anyone tried this approach and
timed it? How much slower is it in the normal case (exec immediately
after fork) and how much faster would programs be that use parallel
processes (e.g. kermit)?

--
|    _  | 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 |