Messages in this thread |  | | | Subject | Re: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptive spinning | | From | Peter Zijlstra <> | | Date | Tue, 06 Apr 2010 17:37:29 +0200 |
| |
On Tue, 2010-04-06 at 08:33 -0700, Darren Hart wrote: > 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.
Sure, but I'm still not sure why FUTEX_LOCK ends up making more syscalls than FUTEX_WAIT based locking. Both should only do the syscall when the lock is contended, both should only ever do 1 syscall per acquire, right?
|  |