Re: Large slab cache in 2.6.1

[Nick Piggin]

Andrew Morton wrote:

> Nick Piggin <piggin@xxxxxxxxxxxxxxx> wrote:
>
> > Andrew Morton wrote:
> >
> >
> > > 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.

This is the incremental min logic doing its work though. Maybe
that should be fixed up to be less aggressive instead of putting
more complexity in the scanner to work around it.

Anyway could you post the patch you're using to fix it?

> 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.

The logical extension of that is: "we want to reclaim *lowmem* in
response to highmem reclaim pressure because any ..."

If this isn't what the scanner is doing then it should be fixed in
a more generic way.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/