From: Davidlohr Bueso
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. While the hash bucket's plist
head is a cheap way of knowing this, we cannot rely 100% on it as there is a
racy window between the futex_wait call and
From: Davidlohr Bueso davidl...@hp.com
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. While the hash bucket's plist
head is a cheap way of knowing this, we cannot rely 100% on it as there is a
racy window between the
On Mon, 25 Nov 2013, Darren Hart wrote:
> On Mon, 2013-11-25 at 20:47 +0100, Thomas Gleixner wrote:
> > So now your code melts down to:
> >
> > write(hb->waiters)|write(uaddr)
> > mb|read(hb->waiters)
> > read(uaddr)
> >
> > I fear you simply managed to make
On Mon, 25 Nov 2013, Darren Hart wrote:
On Mon, 2013-11-25 at 20:47 +0100, Thomas Gleixner wrote:
So now your code melts down to:
write(hb-waiters)|write(uaddr)
mb|read(hb-waiters)
read(uaddr)
I fear you simply managed to make the window small
On Mon, 25 Nov 2013, Darren Hart wrote:
> On Mon, 2013-11-25 at 20:47 +0100, Thomas Gleixner wrote:
> > > which restores the ordering guarantee, which the hash bucket lock
> > > provided so far.
> >
> > Actually that's not true by design, it just happens to work.
> >
> > atomic_inc() on x86 is a
On Mon, 2013-11-25 at 20:47 +0100, Thomas Gleixner wrote:
> On Sat, 23 Nov 2013, Thomas Gleixner wrote:
> > On Fri, 22 Nov 2013, Davidlohr Bueso wrote:
> > So with the atomic ops you are changing that to:
> >
> > CPU 0 CPU 1
> >
> > val = *futex;
> >
On Mon, 25 Nov 2013, Davidlohr Bueso wrote:
> On Mon, 2013-11-25 at 18:32 +0100, Thomas Gleixner wrote:
> > If the smp_mb() is heavy weight, then it will hurt massivly in the
> > case where the hash bucket is not empty, because we add the price for
> > the smp_mb() just for no gain.
> >
> > In
On Sat, 23 Nov 2013, Thomas Gleixner wrote:
> On Fri, 22 Nov 2013, Davidlohr Bueso wrote:
> So with the atomic ops you are changing that to:
>
> CPU 0 CPU 1
>
> val = *futex;
> futex_wait(futex, val);
>
> spin_lock(>lock);
>
>
On Mon, 2013-11-25 at 18:32 +0100, Thomas Gleixner wrote:
> On Mon, 25 Nov 2013, Peter Zijlstra wrote:
> > On Mon, Nov 25, 2013 at 05:23:51PM +0100, Thomas Gleixner wrote:
> > > On Sat, 23 Nov 2013, Linus Torvalds wrote:
> > >
> > > > On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner
> > > >
On Mon, Nov 25, 2013 at 06:32:55PM +0100, Thomas Gleixner wrote:
> In that context it would also be helpful to measure the overhead on
> x86 for the !empty case.
Yes, because mfence is by no means a cheap instruction on x86.
--
To unsubscribe from this list: send the line "unsubscribe
On Mon, 25 Nov 2013, Peter Zijlstra wrote:
> On Mon, Nov 25, 2013 at 05:23:51PM +0100, Thomas Gleixner wrote:
> > On Sat, 23 Nov 2013, Linus Torvalds wrote:
> >
> > > On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner
> > > wrote:
> > > >
> > > > Now the question is why we queue the waiter
On Mon, Nov 25, 2013 at 05:23:51PM +0100, Thomas Gleixner wrote:
> On Sat, 23 Nov 2013, Linus Torvalds wrote:
>
> > On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner wrote:
> > >
> > > Now the question is why we queue the waiter _AFTER_ reading the user
> > > space value. The comment in the code
On Sat, 23 Nov 2013, Linus Torvalds wrote:
> On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner wrote:
> >
> > Now the question is why we queue the waiter _AFTER_ reading the user
> > space value. The comment in the code is pretty non sensical:
> >
> >* On the other hand, we insert q and
On Sat, 23 Nov 2013, Davidlohr Bueso wrote:
> On Sat, 2013-11-23 at 19:46 -0800, Linus Torvalds wrote:
> > On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner wrote:
> > >
> > > Now the question is why we queue the waiter _AFTER_ reading the user
> > > space value. The comment in the code is pretty
On Sat, 23 Nov 2013, Davidlohr Bueso wrote:
On Sat, 2013-11-23 at 19:46 -0800, Linus Torvalds wrote:
On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner t...@linutronix.de wrote:
Now the question is why we queue the waiter _AFTER_ reading the user
space value. The comment in the code is
On Sat, 23 Nov 2013, Linus Torvalds wrote:
On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner t...@linutronix.de wrote:
Now the question is why we queue the waiter _AFTER_ reading the user
space value. The comment in the code is pretty non sensical:
* On the other hand, we insert q
On Mon, Nov 25, 2013 at 05:23:51PM +0100, Thomas Gleixner wrote:
On Sat, 23 Nov 2013, Linus Torvalds wrote:
On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner t...@linutronix.de wrote:
Now the question is why we queue the waiter _AFTER_ reading the user
space value. The comment in the
On Mon, 25 Nov 2013, Peter Zijlstra wrote:
On Mon, Nov 25, 2013 at 05:23:51PM +0100, Thomas Gleixner wrote:
On Sat, 23 Nov 2013, Linus Torvalds wrote:
On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner t...@linutronix.de
wrote:
Now the question is why we queue the waiter _AFTER_
On Mon, Nov 25, 2013 at 06:32:55PM +0100, Thomas Gleixner wrote:
In that context it would also be helpful to measure the overhead on
x86 for the !empty case.
Yes, because mfence is by no means a cheap instruction on x86.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Mon, 2013-11-25 at 18:32 +0100, Thomas Gleixner wrote:
On Mon, 25 Nov 2013, Peter Zijlstra wrote:
On Mon, Nov 25, 2013 at 05:23:51PM +0100, Thomas Gleixner wrote:
On Sat, 23 Nov 2013, Linus Torvalds wrote:
On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner t...@linutronix.de
On Sat, 23 Nov 2013, Thomas Gleixner wrote:
On Fri, 22 Nov 2013, Davidlohr Bueso wrote:
So with the atomic ops you are changing that to:
CPU 0 CPU 1
val = *futex;
futex_wait(futex, val);
spin_lock(hb-lock);
atomic_inc(hb-waiters);
On Mon, 25 Nov 2013, Davidlohr Bueso wrote:
On Mon, 2013-11-25 at 18:32 +0100, Thomas Gleixner wrote:
If the smp_mb() is heavy weight, then it will hurt massivly in the
case where the hash bucket is not empty, because we add the price for
the smp_mb() just for no gain.
In that context
On Mon, 2013-11-25 at 20:47 +0100, Thomas Gleixner wrote:
On Sat, 23 Nov 2013, Thomas Gleixner wrote:
On Fri, 22 Nov 2013, Davidlohr Bueso wrote:
So with the atomic ops you are changing that to:
CPU 0 CPU 1
val = *futex;
futex_wait(futex,
On Mon, 25 Nov 2013, Darren Hart wrote:
On Mon, 2013-11-25 at 20:47 +0100, Thomas Gleixner wrote:
which restores the ordering guarantee, which the hash bucket lock
provided so far.
Actually that's not true by design, it just happens to work.
atomic_inc() on x86 is a lock incl.
On Sat, 2013-11-23 at 19:46 -0800, Linus Torvalds wrote:
> On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner wrote:
> >
> > Now the question is why we queue the waiter _AFTER_ reading the user
> > space value. The comment in the code is pretty non sensical:
> >
> >* On the other hand, we
On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner wrote:
>
> Now the question is why we queue the waiter _AFTER_ reading the user
> space value. The comment in the code is pretty non sensical:
>
>* On the other hand, we insert q and release the hash-bucket only
>* after testing *uaddr.
On Fri, 22 Nov 2013, 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 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
On Fri, 22 Nov 2013, 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 davidl...@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
On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner t...@linutronix.de wrote:
Now the question is why we queue the waiter _AFTER_ reading the user
space value. The comment in the code is pretty non sensical:
* On the other hand, we insert q and release the hash-bucket only
* after testing
On Sat, 2013-11-23 at 19:46 -0800, Linus Torvalds wrote:
On Sat, Nov 23, 2013 at 5:16 AM, Thomas Gleixner t...@linutronix.de wrote:
Now the question is why we queue the waiter _AFTER_ reading the user
space value. The comment in the code is pretty non sensical:
* On the other hand,
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 wrote:
> > > In futex_wake() there is clearly no point in taking the hb->lock if
> > > we know beforehand that there are no
On Fri, 2013-11-22 at 16:56 -0800, Davidlohr Bueso 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.
On Fri, 2013-11-22 at 21:40 -0800, Darren Hart wrote:
> On Fri, 2013-11-22 at 16:56 -0800, Davidlohr Bueso 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
On Fri, 2013-11-22 at 16:56 -0800, Davidlohr Bueso 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.
On 11/22/2013 08:25 PM, Linus Torvalds wrote:
On Fri, Nov 22, 2013 at 4:56 PM, Davidlohr Bueso 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
On Fri, 2013-11-22 at 17:25 -0800, Linus Torvalds wrote:
> On Fri, Nov 22, 2013 at 4:56 PM, Davidlohr Bueso 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
On Fri, Nov 22, 2013 at 5:25 PM, Linus Torvalds
wrote:
> On Fri, Nov 22, 2013 at 4:56 PM, Davidlohr Bueso 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
On Fri, Nov 22, 2013 at 4:56 PM, Davidlohr Bueso 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?
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. Specifically, increment the counter when an element is
added to the list, and
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. Specifically, increment the counter when an element is
added to the list, and
On Fri, Nov 22, 2013 at 4:56 PM, Davidlohr Bueso davidl...@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.
On Fri, Nov 22, 2013 at 5:25 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Nov 22, 2013 at 4:56 PM, Davidlohr Bueso davidl...@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
On Fri, 2013-11-22 at 17:25 -0800, Linus Torvalds wrote:
On Fri, Nov 22, 2013 at 4:56 PM, Davidlohr Bueso davidl...@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
On 11/22/2013 08:25 PM, Linus Torvalds wrote:
On Fri, Nov 22, 2013 at 4:56 PM, Davidlohr Buesodavidl...@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
On Fri, 2013-11-22 at 16:56 -0800, Davidlohr Bueso 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. Specifically,
On Fri, 2013-11-22 at 21:40 -0800, Darren Hart wrote:
On Fri, 2013-11-22 at 16:56 -0800, Davidlohr Bueso 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
On Fri, 2013-11-22 at 16:56 -0800, Davidlohr Bueso 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. Specifically,
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 davidl...@hp.com wrote:
In futex_wake() there is clearly no point in taking the hb-lock if
we know beforehand that there are
48 matches
Mail list logo
