Ed, it's going to take some time/effort to get this shaken down
and into the tree, I expect. There's quite a bit banked up
at present.
I'll take care of any stability and performance stuff in slablru, but
the wider question is: what behaviour do we actually _want_ for slab
pages, and is this code delivering it? Need to think about that. But
we certainly can't do worse than we are at present ;)
I've merged your patch on top of the pagemap_lru_lock patches. A whole
bunch of nastiness went away because those patches allow us to take that
lock from interrupt context.
The locking in slab.c needs some going over - I think it's wrong from a
2.4 perspective: there's one ranking bug between pagemap_lru_lock and
the cachep->spinlock. I'd suggest that you change the 2.4 implementation
to just drop pagemap_lru_lock before calling from vmscan into
kmem_shrink_slab(). One thing will lead to another and the locking in slab
will get simpler. Just make the lru lock nest inside the cachep->spinlock.
The fiddled patch is at http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.30/
I'll read through it a bit more next week, give it a bit of testing.
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/