On 08/01/2015 06:29 PM, Peter Zijlstra wrote:
On Fri, Jul 31, 2015 at 10:21:58PM -0400, Waiman Long wrote:
The smp_store_release() is not a full barrier. In order to avoid missed
wakeup, we may need to add memory barrier around locked and cpu state
variables adding to complexity. As the chance o
On Mon, Aug 03, 2015 at 12:09:42PM -0700, Davidlohr Bueso wrote:
> On Mon, 2015-08-03 at 20:37 +0200, Peter Zijlstra wrote:
> > OK, so there's no 'fix'? The patch claims we can loose a wakeup and I
> > just don't see how that is true.
>
> Taking another look, I think you could hit something like t
On Mon, 2015-08-03 at 20:37 +0200, Peter Zijlstra wrote:
> OK, so there's no 'fix'? The patch claims we can loose a wakeup and I
> just don't see how that is true.
Taking another look, I think you could hit something like this:
CPU0 (lock):CPU1 (unlock):
pv_w
On Mon, Aug 03, 2015 at 11:22:09AM -0700, Davidlohr Bueso wrote:
> On Sun, 2015-08-02 at 00:29 +0200, Peter Zijlstra wrote:
> > That's just gibberish, even in the same cacheline stuff can get
> > reordered.
>
> true dat
>
> >
> > So either
On Sun, 2015-08-02 at 00:29 +0200, Peter Zijlstra wrote:
> That's just gibberish, even in the same cacheline stuff can get
> reordered.
true dat
>
> So either we insert
> > +* memory barrier here and in the corresponding pv_wait_head()
On Fri, Jul 31, 2015 at 10:21:58PM -0400, Waiman Long wrote:
> The smp_store_release() is not a full barrier. In order to avoid missed
> wakeup, we may need to add memory barrier around locked and cpu state
> variables adding to complexity. As the chance of spurious wakeup is very
> low, it is easi
; Ingo Molnar; Thomas Gleixner; H. Peter Anvin;
x...@kernel.org; linux-kernel@vger.kernel.org; Norton, Scott J; Hatch, Douglas
B (HPS Linux PM)
Subject: Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with
_Q_SLOW_VAL
On Fri, 2015-07-31 at 22:21 -0400, Waiman Long wrote:
>
On Fri, 2015-07-31 at 22:21 -0400, Waiman Long wrote:
> The smp_store_release() is not a full barrier. In order to avoid missed
> wakeup, we may need to add memory barrier around locked and cpu state
> variables adding to complexity. As the chance of spurious wakeup is very
> low, it is easier and
8 matches
Mail list logo
