[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: self-paging

From: Bas Wijnen
Subject: Re: self-paging
Date: Tue, 6 Dec 2005 18:28:05 +0100
User-agent: Mutt/1.5.11

On Tue, Dec 06, 2005 at 11:16:12AM -0500, Jonathan S. Shapiro wrote:
> > > Nonsense. What the user wants to do is say "make that one run better".
> > > The user has probably never heard of priority.
> > 
> > If the user doesn't know this is called "giving it higher priority", that
> > doesn't mean it's not what he wants.
> Agreed. My point is that the interface used for most users wants to be
> expressed in simpler terms.

I agree with that.  I would like the ability to "open the hood" for more
advanced users who want to waste their time on tuning all the settings,

> Bas: when we get to the point where we are confused only about our selection
> of words, it's a very good sign!


> > > In EROS/Coyotos, the eviction decisions are made in the kernel guided by
> > > application-defined policy. This is largely because of checkpoint. In
> > > practice, it doesn't seem to restrict the feasible policies.
> > 
> > That sounds ok then.  On the other hand, this seems to be a part which can
> > be moved out of the kernel to user space now you no longer demand that the
> > kernel can handle any misbehaving application, even one in the TCB.
> Probably not. There is still a strong motivation from separation of
> concerns. In order for an application to deal with this, it would need
> access to some data structures that must be updated by the kernel and have
> SMP sensitivities. I think it is better that these data structures always be
> handled by the same party.

Hm, I didn't think about SMP at all.  Anyway, for this discussion it doesn't
really matter if it is in the kernel or not.  And with the new (to me)
definition of a space bank, I even agree that the list should be in the
kernel. :-)  See below.

> > > Yes, the problem is that the kernel is now going to have to ask two
> > > parties for an eviction policy, and (whichever one is chosen) it will
> > > pick the wrong one to ask...
> > 
> > There is no "wrong one".  When the kernel wants to increase the physical
> > memory quota of a process (and there are no unused pages), it will have to
> > decrease someone else's quota.
> 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.

> > 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
the level at which the list I propose should reside.  Since an address space
doesn't have an executable part, except for the untrusted user code, it can
only manage the list if a thread for that purpose is added.  It seems better
to put it in the kernel instead (since it is only run when the process
requests it, it doesn't make sense to make it a thread).

You said before that the list management would need to be in the kernel if it
would be implemented.  I now agree with that. :-)


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]