Re: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptivespinning
From: Darren Hart
Date: Tue Apr 06 2010 - 11:33:42 EST
Peter Zijlstra wrote:
On Tue, 2010-04-06 at 07:47 -0700, Ulrich Drepper wrote:
On Tue, Apr 6, 2010 at 01:48, Peter Zijlstra <peterz@xxxxxxxxxxxxx>
tryThis is available for a long time in the mutex implementation
(PTHREAD_MUTEX_ADAPTIVE_NP mutex type). It hasn't show much
improvement if any. There were some people demanding this support for
as far as I know they are not using it now. This is adaptive
spinning, learning from previous calls how long to wait. But it's
still unguided. There is no way to get information like "the owner
has been descheduled".
That's where the FUTEX_LOCK thing comes in, it does all those, the above
was a single spin loop to amortize the syscall overhead.
I wouldn't make it any more complex than a single pause ins, syscalls
are terribly cheap these days.
And yet they still seem to have a real impact on the futex_lock
benchmark. Perhaps I am just still looking at pathological cases, but
there is a strong correlation between high syscall counts and really low
iterations per second. Granted this also correlates with lock
contention. However, when using the same period and duty-cycle I find
that a locking mechanism that makes significantly fewer syscalls also
significantly outperforms one that makes more. Kind of handwavy stilly,
I'll have more numbers this afternoon.
IBM Linux Technology Center
Real-Time Linux Team
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/