>>>>> "andi" == Andi Kleen <ak@suse.de> writes:
andi> On Tue, Jun 06, 2000 at 08:07:34AM -0700, Chris Mason wrote:
>>
>>
>> On Tue, 6 Jun 2000, Andi Kleen wrote:
>>
>> > On Tue, Jun 06, 2000 at 06:30:03AM -0700, Chris Mason wrote:
>> > > We need two things:
>> > >
>> > > 1) a way to reserve and release a pinned page count. This will allow a
>> > > pinned page high watermark so the journaled filesystems can plan nice
>> > > without pinning all the ram.
>> > >
>> > > 2) A memory pressure call back in the address space operations. This
>> > > really does seem more flexible than a call in struct super_operations.
>> >
>> > This would involve that the pages in the transaction are added to the global
>> > LRU (otherwise there would be no easy way to get at their transactions).
>> > Does that really make sense ?
>>
>> Once shrink_mmap (or similar function) uses the call back from any page
>> in the FS, I can use that to start reclaiming.
andi> That sounds like quite a gamble: hope that the core shrink_mmap code
andi> which knows nothing about such tricks hits some page that is part of
andi> a transaction to free a lot of other unrelated pages. I guess a more
andi> direct approach would be better and safer.
As I spoted in other mail, I preffer to call a registered function to
free pages. It makes no sense to do that kind of notification. One
of the reasons is that if shrink_mmap hits *two* (put here any number)
consecutive pages of your cache, you would try to free pages every
time. I think that pages in the LRU cache should be *freeable*
without any other requeriment. If they are not freeable without more
restrictions, why are we putting them in one LRU queue. We are not
honouring the LRU queue anyway. Note also that with the recent
changes in the VM cache, we begin with a bigger priority (64 instead
of 6), that means that in first round we ask all the caches to return
(nr_elements/64), that is quite small number and we will go to all the
caches before shrink too much the first one. With the old code, the
LRU cache was shrinked too fast and the rest of the caches was
shrinked only when the memory pressure was *too* high.
Later, Juan.
-- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:27 EST