Re: ext3 inode cache eats system, news at 11

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andrew Morton wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>> Andrew Morton wrote:
>>
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc2/2.6.6-rc2-mm2/broken-out/slab-order-0-for-vfs-caches.patch
>> > 
>> > is not a completely happy solution, but it should fix things up.
>>
>> Another thing you could be doing is not zeroing swapper->nr
>> if the shrinker function doesn't do anything, in order to try
>> to maintain pressure on the dcache. This would be similar to
>> your deferred list idea.
> 
> 
> Am now doing this.
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc2/2.6.6-rc2-mm2/broken-out/shrink_slab-handle-GFP_NOFS.patch
> 

Ahh good. You may want to subtract the pending ->nr from
"(*shrinker->shrinker)(0, gfp_mask)" though, when calculating
the size of the next delta to scan.

Well possibly not. The math in your patch presently assumes
no entries will be freed due to the built up deferred scanning,
and if you changed it to the above idea, it would assume all
entries will be freed. I just think it would be good to dampen
the increase to ->nr a bit. It would inherently limit ->nr from
wrapping too.