Re: [PATCH 0/2] convert mmap_sem to a scalable rw_mutex

[Nick Piggin <npiggin@suse.de>]

On Fri, May 11, 2007 at 05:56:21PM +0200, Ingo Molnar wrote:
> 
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> 
> > I was toying with a scalable rw_mutex and found that it gives ~10% 
> > reduction in system time on ebizzy runs (without the MADV_FREE patch).
> > 
> > 2-way x86_64 pentium D box:
> > 
> > 2.6.21
> > 
> > /usr/bin/time ./ebizzy -m -P
> > 59.49user 137.74system 1:49.22elapsed 180%CPU (0avgtext+0avgdata 0maxresident)k
> > 0inputs+0outputs (0major+33555877minor)pagefaults 0swaps
> > 
> > 2.6.21-rw_mutex
> > 
> > /usr/bin/time ./ebizzy -m -P
> > 57.85user 124.30system 1:42.99elapsed 176%CPU (0avgtext+0avgdata 0maxresident)k
> > 0inputs+0outputs (0major+33555877minor)pagefaults 0swaps
> 
> nice! This 6% runtime reduction on a 2-way box will i suspect get 
> exponentially better on systems with more CPUs/cores.

Is this with the MADV_DONTNEED kernel and glibc work?


> i also like the design, alot: instead of doing a full new lock type 
> (with per-arch changes, extra lockdep support, etc. etc) you layered the 
> new abstraction ontop of mutexes. This makes this hard locking 
> abstraction look really, really simple, while the percpu_counter trick 
> makes it scale _perfectly_ for the reader case. Congratulations!
> 
> given how nice this looks already, have you considered completely 
> replacing rwsems with this? I suspect you could test the correctness of 

Not to take anything away from this lock type (because it can have its
uses), but have you considered the size of this lock and its write side
performance? 

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