lkml.org 
[lkml]   [2004]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ext3 inode cache eats system, news at 11
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.034 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site