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.143309.6199@email.tuwien.ac.at> Date: 17 May 91 14:33:09 GMT References: <53831@nigel.ee.udel.edu> Sender: news@email.tuwien.ac.at Distribution: "world" Organization: Technical University of Vienna, Dept. for Realtime Systems Lines: 111 Nntp-Posting-Host: nowhere.vmars.tuwien.ac.at tsarna@polar.bowdoin.edu (Tyler Sarna) writes: >Peter Holzer writes: >> [...] >> Process control should go into the kernel, IMHO. (I guess, I will get a >> lot of flames for this) >Yes, but this is such a major change that the resultant system >would barely be minix anymore, and any possibility of upgrading >to a new version of Minix (say 2.0) would be virtually nil. Not >that the whole venture itself doesn't imply many, many changes, >but the number should be kept as low as possible. Well, of course this change should be incorporated into 2.0 (ducks). >> >> most likely, the kernel uses a 'flat' address space. >> >> >FS and MM can be flat too. It might be easier. >> >> They are not flat now on 80x86 Minix. I see no reason to introduce such >> a big conceptual difference between PC-Minix and Atari-Minix. >Who said Atari? This applies to any 68k minix (sorry, pet >peeve). This is not "introducing", so much as keeping things the >way they are now. Sorry, of course I meant 68k-Minix in general, not just Atari-Minix. They are identical at this level, aren't they? How does FS copy data from a user process into its buffers? On the PC it sends a message to systask to copy the data. Does it the same on 68K-Minix (You see, I learn :-), or does it copy directly (via memcpy). I know it could do it directly, because all processes share the same address space, but I don't think it does. >> >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). >Sure it will work. If things not being in the same place in >memory was in insurmountable problem, we wouldn't now be talking >about virtual addreses, would we? The MMU can be used to map the >bottom of the data segment right after the code segment, and the >top of the segment at the top of the virtual address space. If >the stack of data space needs to grow, we simply move the stack >space up in real memory. The mapping takes care of everything. There are two kinds of VM: Segmentation and paging. Minix now (on 80x86 machines) uses segmentation. So for each segment, physical address is base address + virtual address. If the maximum segment size is larger than physical memory, you can create one segment with base address zero and size == physical mem. size that covers all existing memory and can be used to access memory inside all other segments (e.g. for copying data from one segment to another). This is done on the 386. If a pointer is large enough to hold both the segment number and the offset, you can use separate segments for stack and data. Both can grow independently and be copied to different physical addresses as you said. I think most MMU's for 68k-processors that support segmenting do it like this so you have no problem and can forget chmem. On Intel processors however (sorry for mentioning that brain-damage, but I have one, so I have to cope with it) segment and offset do not fit into one machine word, so you have two possibilities: Either you split your pointers over two machine words, which makes C-programs rather inefficient (because optimizers don't cope well with such huge variables and loading segment registers is costly) or you put stack and data into the same segment. This was done on Minix, and is the reason for the chmem kludge. The second possibility is to use paging. Give every process the whole address range of virtual memory, map only pages that are actually used to physical memory and change this mapping on every context switch. This is done in every Unix-implementation I know, and it works well, because kernel and the active process share the same virtual memory. On Minix, it is ugly, because FS and MM are in fact user processes (although privileged0 ones) and they frequently have to ask the kernel to copy data from them to their clients and vice versa. So the kernel would have to switch between page tables frequently while copying or it would have to construct a special page table which contains the address space of both processes just for copying. (Reserving a range for each layer as I mentioned in my last posting, doesn't help much, because MM and FS are also calling each other, and when (or if) other servers are added, the situation gets worse) >> But, most programs only use limited stack space but want to malloc lots >> of data. So you could reserve a limited area at the _beginning_ of the >Look at the GNU tools. They allocate massive amounts of space on >the stack with alloca. Hmm, I hadn't thought of that. But anyway, even they seem to use much less stack than heap. I have seen gcc use 40MB heap, but it never exceeded its stack limit of 512k on our DECstations. >At any rate, it looks doable to me. I don't doubt it is doable if you have a sane MMU. I just wanted to propose a solution that is independent of the MMU and works with minor changes to the compiler even without one. -- | _ | 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 |