Re: [patch 0/6] lightweight robust futexes: -V3 - Why in userspace?

Ingo Molnar
2006-02-16T20:38:27Z

* Esben Nielsen <simlo@phys.au.dk> wrote:

> > On Thu, 2006-02-16 at 20:06 +0100, Esben Nielsen wrote:
> > > I just jump into a thread somewhere to ask my question :-)
> > >
> > > Why does the list have to be in userspace?
> >
> > because it's faster ;)
> >
> >
> Faster???

yes, it's faster.

> As I see it, extra manipulations have to be done even in the non-congested
> case: Every time the lock is taken the locking thread has to add the lock
> to a the list, and reversely remove the lock from the list. I.e.
> instructions are _added_ to the fast path where you stay purely in
> userspace.

Note that glibc was already doing these list ops for the current
(limited, userspace-only) implementation of robust mutexes, so moving
the cleanup to kernel-space has only a small effect on the userspace
fastpath.

even considering the list ops, they are 2-3 (non-LOCK-ed) instructions
of memory values that are already cached => it's almost for free. Ulrich
(who is a kind of person who writes glibc code in assembly whenever he
can excuse it with a performance argument) would be pretty upset if it
wasnt cheap :-)

> I am ofcourse comparing to a solution where you do a syscall on
> everytime you do a lock. What I am asking about is whethere it
> wouldn't be enough to maintain the list at the FUTEX_WAIT/FUTEX_WAKE
> operation - i.e. the slow path where you have to go into the kernel.

no, that's not enough at all: we need to be able to clean up after
futexes even if the kernel was _never involved_ with them. The pure
userspace futex fastpath still can keep a lock stuck! In fact that is
the common-case.

Ingo