Messages in this thread | | | Subject | Re: [PATCH 4/5] futex: Avoid taking hb lock if nothing to wakeup | From | Darren Hart <> | Date | Fri, 22 Nov 2013 23:23:11 -0800 |
| |
On Fri, 2013-11-22 at 19:19 -0800, Davidlohr Bueso wrote: > On Fri, 2013-11-22 at 17:25 -0800, Linus Torvalds wrote: > > On Fri, Nov 22, 2013 at 4:56 PM, Davidlohr Bueso <davidlohr@hp.com> wrote: > > > In futex_wake() there is clearly no point in taking the hb->lock if > > > we know beforehand that there are no tasks to be woken. This comes > > > at the smaller cost of doing some atomic operations to keep track of > > > the list's size. > > > > Hmm. Why? Afaik, you only care about "empty or not". And if you don't > > need the serialization from locking, then afaik you can just do a > > "plist_head_empty()" without holding the lock. > > I remember this being the original approach, but after noticing some > strange behavior we quickly decided it wasn't the path. And sure enough, > I just double checked and tried the patch without atomic ops and can see > things being off: one of the futextest performance cases is stuck > blocked on a futex and I couldn't reboot the machine either -- nothing > apparent in dmesg, just not 100% functional. The thing is, we can only > avoid taking the lock only if nobody else is trying to add itself to the > list.
In your usage, the worst case scenario is that you detect 0 when locking may have blocked and found a waiter. Correct?
In this case, you return 0, instead of 1 (or more).
This suggests to me a bug in the futextest testcase. Which test specifically hung up waiting?
Futex hangs are almost always bad userspace code (my bad userspace code in this case ;-)
-- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
| |