Re: Futexes III : performance numbers

[Hubertus Franke <frankeh@watson.ibm.com>]

On Wednesday 06 March 2002 02:54 am, Rusty Russell wrote:
> On Tue, 5 Mar 2002 16:23:14 -0500
>
> Hubertus Franke <frankeh@watson.ibm.com> wrote:
> > Interesting... the strict FIFO ordering of my fast semaphores limits
> > performance as seen by 99.71% contention, so we always ditch
> > into the kernel. Convoy Avoidance locks 2.5 times better.
> > Wohh futex rock, BUT... with 0.29% contention it basically tells
> > me that we are exhausting our entire quantum getting the lock
> > without contention. So their is some serious fairness issue here
> > at least for the tightly scheduled locks. Compare the M numbers
> > for 2 and 3 children.
>
> Fairness <sigh>.  This patch should be much more FIFO: it works by handing
> the mutex straight to the first one on the queue if there is one, and only
> actually "freeing" it if there's noone waiting.
>
> Unfortunately, it seems to hurt performance by 50% on tdbtorture (although
> there are weird scheduler things happening too).
>
> Here's the "fair" patch:
> Rusty.

Thanks, Rusty, man you are a coding machine :-)

Now you are experiencing all the issues that I went through as well.
Point I was trying ot make is, that there is not cookie cutter solution.
One must provide the various options to the higher level and let
the application choose what mootex semantics it wants.

There is applicability for fair futexes and for convoy avoidance futexes.

So let's put both in, and later expand it to read/write stuff.


-- 
-- Hubertus Franke  (frankeh@watson.ibm.com)