On Tue, 2005-12-06 at 18:28 +0100, Bas Wijnen wrote: > On Tue, Dec 06, 2005 at 11:16:12AM -0500, Jonathan S. Shapiro wrote:
> > When sharing is considered, this stops being true. Suppose you and I both > > need a page and have assigned it a position. I need it badly, you need it > > less badly. You fault, and your pager says "shoot that one". The problem is > > that I still need it. Getting this right requires a unified management > > scheme for shared items. > > My pager can say "shoot that one" for example by swapping it with a page which > is currently not mapped in my memory. If the old one is shared, and the new > one isn't, then I should get a new page if it is available (and my quota > should probably decrease a bit in the next adjustment round), or my quota > should be decreased immediately if there is no new page available. As long as > you have the page in your memory, it will not really be thrown out. It's just > thrown out of my address space. > > I think this isn't a big thing: most shared pages will be libraries, and I > think they will usually be somewhere at the start of the list. And anyway, > they're extremely fast to be mapped in from "swap", because they don't have to > actually come from disk. It is a *very* big thing. You have just created a design where one RT process can evict a frame required by another. The reason your design has this problem is that you have the quotas attached in the wrong place. What you need to resolve this is a subdivisible quota mechanism that allows you to attach different quotas to different pools. A shared pool of frames needs to have exactly one quota, and this quota should not (usually) be used to cover any other pool. It's a granularity issue. You want the granularity of residency to be independent of the granularity of either process or address space. Another example: you definitely want to processes that share an address space to share all of the same residency properties (think: symmetric multithreading). > > > > Ok, perhaps I didn't understand what a space bank is. Here's what I > > > thought: A space bank gives space to store things. Storage is either on > > > disk, or in memory, or both. Storage on disk is "swapped out". Storage > > > in memory and on disk is normal memory, with a reserved place to put it > > > when it will be swapped out. Storage only in memory is cache, which is > > > lost when it would be swapped out. > > > > Okay. I understand what you thought, but it doesn't work that way. In a > > persistent system, *all* pages are disk pages, and residency is managed > > orthogonally. > > I think that depends on the level at which you look at it. Space banks are > appearantly a bit lower level than I expected. However, at the address space > level, there are pages in memory which have storage in a space bank. This is not so. Address spaces have no intrinsic relationship to memory in the sense that you mean. An address space is an object (actually, a collection of objects) that defines a mapping from page address to [disk] pages. The residency of the components of the address space is a separate thing. Address spaces can even exist without any process. > You said before that the list management would need to be in the kernel if it > would be implemented. I now agree with that. :-) Good. Now tackle the *rest* of the challenge problem: how to manage this list sensibly in constant per-frame storage in the face of sharing. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
