Re: [patch 1/3] slob: rework freelist handling

Christoph Lameter
2007-05-24T16:36:16Z

On Thu, 24 May 2007, Matt Mackall wrote:

> So, here's three possible approaches to this issue:
>
> A) Continue to ignore it. Doing something about it would add
> complexity and it's not clear that it's a win.
>
> B) Set NR_SLAB_RECLAIMABLE to 1. If the VM starts checking that to
> decide whether it should call shrinkers, things will continue to work.
> Increment and decrement NR_SLAB_UNRECLAIMABLE when we grow/shrink the
> SLOB pool. This is probably 3 lines of code total.
>
> C) Fake NR_SLAB_RECLAIMABLE/NR_SLAB_UNRECLAIMABLE based on actual
> allocs and slab flags such that they sum to the total pages in the
> SLOB pool. This would need a third global counter in bytes of how many
> allocs we had in the "reclaimable" slabs. Probably 10-20 lines of
> code of marginal utility.
>
> So, nothing insurmountable here. Just not convinced we should bother.
> But the cost of B is so low, perhaps I might as well.

D) Do the right thing and implement the counters.

At the time of calling alloc_pages() you know that you have to increment
either counter but you do not know which.

For that purpose you add another byte counter (reclaim_counter) that
contains the number of reclaimable bytes allocated. Sum them up during
slob_alloc if flags & SLAB_RECLAIM_ACCOUNT is set.

Then after a page allocator alloc you check the following:

If (NR_SLAB_RECLAIMABLE << PAGE_SHIFT) >= reclaim_counter then increment
NR_SLAB_UNRECLAIMABLE otherwise NR_SLAB_RECLAIMABLE.