Re: self-paging

[Emmanuel Colbus]

Jonathan S. Shapiro a écrit :

>  On Tue, 2005-12-06 at 00:05 +0100,
Emmanuel Colbus wrote:
> > On Sun, 04 Dec 2005 14:26:28 -0500, Jonathan S. Shapiro wrote:
> >
> >> I provisionally believe that if we want to use any sort of
LRU,
> >> the gathering of age data must be performed by the kernel.
Since
> >> the kernel needs to collect this data anyway,
> >
> > Why does it?
>
>
>  Because the kernel is in a position to use the translation hardware
>  in order to measure this. Applications, generally speaking, are
not.

I meant : why does the kernel needs to collect the data *anyway*, that is,
even if we don't use any kind of LRU. Clearly, if this data has to be 
collected,
only the kernel can do it.

> >> I think that *one* of the policies we should have is "LRU
w.r.t.
> >> the rest of the pool" and that this should be directly
> >> implemented by the kernel.
> >
> > Doesn't it suffers from the same covert channel problem? I'm
> > thinking about two applications which would manage to always
have
> > their pages very recently used, and to use each one nearly the
half
> > of the memory.
>
>
>  I don't think so, because this is LRU **with respect to a pool**.
If
>  two applications are sharing a pool, they are already in direct
>  communication, and considerations of covert channels become
>  irrelevant.

Oh, I did not realized you proposed many different and separated
pools, sorry.

> >> One part of this differs from what Bas seems to be
proposing: we
> >> want to be able to associate pools with regions of the
virtual
> >> space as opposed to the entire space. The issue is that we
may
> >> want to manage the residency of shared objects on some
collective
> >> basis, and to do this, we need to be able to associate
pools with
> >> memory objects.
> >
> > Yes, but how would this be an issue? To handle object sharing,
we
> > just need to tell the keeper "the age of this page has to be
> > recorded HERE (a location which is the same for anybody
sharing the
> > page)"...
>
>
>  That definitely won't work. The thing we are sharing may be
>  read-only. Adding the requirement for a shared mutable region
causes
>  it to become read-write, and therefore a communication channel.

Oh, yes, I didn't thought to that. Well, I don't know how these regions
should be handled, then.

> >> The second issue is that I haven't thought through how to
go
> >> about getting *inbound* information to the pool keeper.
Does the
> >> keeper need to know about the order of page inserts?
> >
> > I don't think so - what would it be good for?
>
>
>  Well, if the keeper doesn't know the order of page arrival, how
does
>  it decide what to throw out? Suppose we wanted to implement LRU in
>  the keeper, for example. How does it know?


It uses the "accessed" bit in the page table entry : if it is 0, the page
hasn't been accessed since the last time the keeper set it to 0, so its
new age is "previous age + 1 keeper cycle time"; if it is 1, its new age
is 0. At page arrival, "previous age" is set to 0 (or was set to 0 for 
long,
because it is also the value for unused pages); but the keeper can't
differentiate such a page from a recently accessed one.

>  shap

Emmanuel