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

[Esben Nielsen <nielsen.esben@googlemail.com>]

On Sat, 12 May 2007, Eric Dumazet wrote:

> Esben Nielsen a écrit :
> >  On Sat, 12 May 2007, Peter Zijlstra wrote:
> >
> > >  On Sat, 2007-05-12 at 11:27 +0200, Esben Nielsen wrote:
> > > > 
> > > >  On Fri, 11 May 2007, Peter Zijlstra 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).
> > > > > 
> > > > 
> > > >  You break priority enheritance on user space futexes! :-(
> > > >  The problems is that the futex waiter have to take the mmap_sem. And 
> > > >  as
> > > >  your rw_mutex isn't PI enabled you get priority inversions :-(
> > > 
> > >  Do note that rwsems have no PI either.
> > >  PI is not a concern for mainline - yet, I do have ideas here though.
> > > 
> > >
> >  If PI wasn't a concern for mainline, why is PI futexes merged into the
> >  mainline?
>
> If you really care about futexes and mmap_sem, just use private futexes, 
> since they dont use mmap_sem at all.

futex_wait_pi() takes mmap_sem. So does futex_fd(). I can't see a code 
path into the PI futexes which doesn't use mmap_sem.

There is another way to avoid problems with mmap_sem:
Use shared memory for data you need to share with high priority tasks and
normal low priority tasks there. The high priority task(s) run(s) in 
an isolated high priority process having its own mmap_sem. This high 
priority process is mlock'ed and doesn't do any operations write locking 
mmap_sem.

But it would be nice if you can avoid such a cumbersome workaround...

Esben