Re: [patch 12/26] SLUB: Slab defragmentation core

[Andrew Morton]

On Tue, 26 Jun 2007 11:19:26 -0700 (PDT)
Christoph Lameter <clameter@xxxxxxx> wrote:

>  
> > But slab_lock() isn't taken for slabs whose objects are larger than 
> > PAGE_SIZE. How's that handled?
> 
> slab lock is always taken. How did you get that idea?

Damned if I know.  Perhaps by reading slob.c instead of slub.c.  When can
we start deleting some slab implementations?

> > How much testing has been done on this code, and of what form, and with
> > what results?
> 
> I posted them in the intro of the last full post and then Michael 
> Piotrowski did some stress tests.
> 
> See http://marc.info/?l=linux-mm&m=118125373320855&w=2

hm, OK, thin.

I think we'll need to come up with a better-than-usual test plan for this
change.  One starting point might be to ask what in-the-field problem
you're trying to address here, and what the results were.


Also, what are the risks of meltdowns in this code?  For example, it
reaches the magical 30% ratio, tries to do defrag, but the defrag is for
some reason unsuccessful and it then tries to run defrag again, etc.

And that was "for example"!  Are there other such potential problems in
there?  There usually are, with memory reclaim.


(Should slab_defrag_ratio be per-slab rather than global?)
-
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/