[Top][All Lists]

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

Re: self-paging

From: Emmanuel Colbus
Subject: Re: self-paging
Date: Wed, 07 Dec 2005 11:30:44 +0100
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

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
>> the gathering of age data must be performed by the kernel.
>> 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

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
>> 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
> their pages very recently used, and to use each one nearly the
> of the memory.

 I don't think so, because this is LRU **with respect to a pool**.
 two applications are sharing a pool, they are already in direct
 communication, and considerations of covert channels become

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
>> space as opposed to the entire space. The issue is that we
>> want to manage the residency of shared objects on some
>> 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,
> 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
 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
>> 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
 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.



reply via email to

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