Messages in this thread | | On Mon, Feb 01, 2010 at 11:10:13AM +0100, Andi Kleen wrote: > On Mon, Feb 01, 2010 at 06:08:35PM +1100, Nick Piggin wrote: > > I always preferred to do defrag in the opposite way. Ie. query the > > slab allocator from existing shrinkers rather than opposite way > > around. This lets you reuse more of the locking and refcounting etc. > > I looked at this for hwpoison soft offline. > > But it works really badly because the LRU list ordering > has nothing to do with the actual ordering inside the slab pages.
No, you don't *have* to follow LRU order. The most important thing is if you followed what I wrote is to get a pin on the objects and the slabs via the regular shrinker path first, then querying slab rather than calling into all these subsystems from an atomic, and non-slab-reentrant path.
Following LRU order would just be the first and simplest cut at this.
> Christoph's basic approach is more efficient.
I want to see numbers because it is also the far more complex approach.
> > So you have a pin on the object somehow via the normal shrinker path, > > and therefore you get a pin on the underlying slab. I would just like > > to see even performance of a real simple approach that just asks > > whether we are in this slab defrag mode, and if so, whether the slab > > is very sparse. If yes, then reclaim aggressively. > > The typical result is that you need to get through most of the LRU > list (and prune them all) just to free the page.
Really? If you have a large proportion of slabs which are quite internally fragmented, then I would have thought it would give a significant improvement (aggressive reclaim, that is).
> > If that doesn't perform well enough and you have to go further and > > It doesn't.
Can we see your numbers? And the patches you tried?
Thanks, Nick
| |