lkml.org 
[lkml]   [2010]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptive spinning
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@infradead.org>
>> wrote:
>>> try
>>> spin
>>> try
>>> syscall
>> This 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.

--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team


\
 
 \ /
  Last update: 2010-04-06 17:35    [W:0.461 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site