On Tue, 26 Jun 2007 11:19:26 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
