>
> * Lee Schermerhorn <Lee.Schermerhorn@hp.com> 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.
