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

Matt Mackall
2007-05-24T17:22:51Z

On Thu, May 24, 2007 at 09:36:16AM -0700, Christoph Lameter wrote:
> 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.

That's C) above. But you haven't answered the real question: why
bother? RECLAIMABLE is a bogus number and the VM treats it as such. We
can make no judgment on how much memory we can actually reclaim from
looking at reclaimable - it might very easily all be pinned.

RECLAIMABLE+UNRECLAIMABLE is a more interesting number - the total
memory used by the allocator. But that's mostly interesting as a
user-level diagnostic.

--
Mathematics is the supreme nostalgia of our time.