On Thu, Nov 01, 2007 at 04:46:36PM +0100, Ingo Molnar wrote: > > * Lee Schermerhorn <[EMAIL PROTECTED]> wrote: > > > > I guess it was done to make the "template" hacks eaiser. I don't > > > really find that in good taste, especially for important core > > > infrastructure. Anyway. > > > > Actually, what I had/have is a cond_resched_rwlock() that I needed to > > convert the i_mmap_lock() to rw for testing reclaim scalability. > > [I've seen a large system running an Oracle OLTP load hang spitting > > "cpu soft lockup" messages with all cpus spinning on a i_mmap_lock > > spin lock.] One of the i_mmap_lock paths uses cond_resched_lock() for > > spin locks. To do a straight forward conversion [and maybe that isn't > > the right approach], I created the cond_resched_rwlock() function by > > generalizing the cond_sched_lock() code and creating both spin and rw > > lock wrappers. I took advantage of the fact that, currently, > > need_lockbreak() is a macro and that both spin and rw locks have/had > > the break_lock member. Typesafe functions would probably be > > preferrable, if we want to keep break_lock for rw spin locks. > > > > Here's the most recent posting: > > > > http://marc.info/?l=linux-mm&m=118980356306014&w=4 > > > > See the changes to sched.[ch]. Should apply to 23-mm1 with offsets > > and minor fixup in fs/inode.c. > > yep. I'm too in favor of keeping the need-lockbreak mechanism and its > type-insensitive data structure. We've got way too many locking > primitives and keeping them all sorted is nontrivial already.
I think a large contributor to that is being a bit clever with indirections and cute code (eg. like this template stuff), rather than having two types of spinlocks instead of one. - 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/
