Re: Large slab cache in 2.6.1

[Andrew Morton <akpm@osdl.org>]

Nick Piggin <piggin@cyberone.com.au> wrote:
>
> 
> 
> Andrew Morton wrote:
> 
> >Chris Wedgwood <cw@f00f.org> wrote:
> >
> >>On Sun, Feb 22, 2004 at 05:35:09PM +1100, Nick Piggin wrote:
> >>
> >>
> >>>Can you maybe use this patch then, please?
> >>>
> >>I probably need to do more testing, but the quick patch I was using
> >>against mainline (bk head) works better than this against 2.5.3-mm2.
> >>
> >
> >The patch which went in six months or so back which said "only reclaim slab
> >if we're scanning lowmem pagecache" was wrong.  I must have been asleep at
> >the time.
> >
> >We do need to scan slab in response to highmem page reclaim as well. 
> >Because all the math is based around the total amount of memory in the
> >machine, and we know that if we're performing highmem page reclaim then the
> >lower zones have no free memory.
> >
> >
> 
> I don't understand this. Presumably if the lower zones have no free
> memory then we'll be doing lowmem page reclaim too, and that will
> be shrinking the slab.

We should be performing lowmem page reclaim, but we're not.  With some
highmem/lowmem size combinations the `incremental min' logic in the page
allocator will prevent __GFP_HIGHMEM allocations from taking ZONE_NORMAL
below pages_high and kswapd then does not perform page reclaim in the
lowmem zone at all.  I'm seeing some workloads where we reclaim 700 highmem
pages for each lowmem page.  This hugely exacerbated the slab problem on
1.5G machines.  I have that fixed up now.

Regardless of that, we do, logically, want to reclaim slab in response to
highmem reclaim pressure because any highmem allocation can be satisfied by
lowmem too.