[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 07 Dec 2005 11:30:44 +0100
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
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
>> One part of this differs from what Bas seems to be
>> 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
>> 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
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.
>> 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
because it is also the value for unused pages); but the keeper can't
differentiate such a page from a recently accessed one.
Re: self-paging, Bas Wijnen, 2005/12/05
Re: self-paging, Emmanuel Colbus, 2005/12/05
Re: self-paging, Bas Wijnen, 2005/12/07
- Re: self-paging, (continued)