lkml.org 
[lkml]   [2007]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/4] spinlock: lockbreak cleanup

* 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. I wouldnt
mind seeing the need_lockbreak flag move into one of the high bits of
spinlocks though, to compress size.

Ingo
-
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/

\
 
 \ /
  Last update: 2007-11-01 16:49    [W:0.055 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site