All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	USB list <linux-usb@vger.kernel.org>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Memory barrier needed with wake_up_process()?
Date: Mon, 5 Sep 2016 10:08:36 +0200	[thread overview]
Message-ID: <20160905080836.GV10153@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1609031009500.768-100000@netrider.rowland.org>

On Sat, Sep 03, 2016 at 10:16:31AM -0400, Alan Stern wrote:

> > Sorry, but that is horrible code. A barrier cannot ensure writes are
> > 'complete', at best they can ensure order between writes (or reads
> > etc..).
> 
> The code is better than the comment.  What I really meant was that the 
> write of bh->state needs to be visible to the thread after it wakes up 
> (or after it checks the wakeup condition and skips going to sleep).

Yeah, I got that.

> > Also, looking at that thing, that common->thread_wakeup_needed variable
> > is 100% redundant. All sleep_thread() invocations are inside a loop of
> > sorts and basically wait for other conditions to become true.
> > 
> > For example:
> > 
> > 	while (bh->state != BUF_STATE_EMPTY) {
> > 		rc = sleep_thread(common, false);
> > 		if (rc)
> > 			return rc;
> > 	}
> > 
> > All you care about there is bh->state, _not_
> > common->thread_wakeup_needed.
> 
> You know, I never went through and verified that _all_ the invocations 
> of sleep_thread() are like that. 

Well, thing is, they're all inside a loop which checks other conditions
for forward progress. Therefore the loop inside sleep_thread() is
pointless. Even if you were to return early, you'd simply loop in the
outer loop and go back to sleep again.

> In fact, I wrote the sleep/wakeup 
> routines _before_ the rest of the code, and I didn't know in advance 
> exactly how they were going to be called.

Still seems strange to me, why not use wait-queues for the first cut?

Only if you find a performance issue with wait-queues, which cannot be
fixed in the wait-queue proper, then do you do custom thingies.

Starting with a custom sleeper, just doesn't make sense to me.

> > That said, I cannot spot an obvious fail, but the code can certainly use
> > help.
> 
> The problem may be that when the thread wakes up (or skips going to 
> sleep), it needs to see more than just bh->state.  Those other values 
> it needs are not written by the same CPU that calls wakeup_thread(), 
> and so to ensure that they are visible that smp_wmb() really ought to 
> be smp_mb() (and correspondingly in the thread.  That's what Felipe has 
> been testing.

So you're saying something like:


	CPU0		CPU1		CPU2

	X = 1				sleep_thread()
			wakeup_thread()
					r = X

But how does CPU1 know to do the wakeup? That is, how are CPU0 and CPU1
coupled.

  reply	other threads:[~2016-09-05  8:08 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-02 18:10 Memory barrier needed with wake_up_process()? Alan Stern
2016-09-02 18:47 ` Paul E. McKenney
2016-09-02 20:29   ` Alan Stern
2016-09-03  9:07     ` Paul E. McKenney
2016-09-03 12:31     ` Peter Zijlstra
2016-09-03 14:26       ` Alan Stern
2016-09-03 14:49         ` Alan Stern
2016-09-05  8:33           ` Peter Zijlstra
2016-09-05 15:29             ` Alan Stern
2016-09-06 11:36               ` Peter Zijlstra
2016-09-06 11:43                 ` Felipe Balbi
2016-09-06 11:49                   ` Peter Zijlstra
2016-09-06 12:20                     ` Peter Zijlstra
2016-09-06 14:46                       ` Alan Stern
2016-09-06 15:05                         ` Peter Zijlstra
2016-09-07 10:12                         ` Felipe Balbi
2016-09-09 10:36                           ` Felipe Balbi
2016-09-09 16:12                             ` Alan Stern
2016-09-19 11:11                               ` Felipe Balbi
2016-09-19 17:35                                 ` Alan Stern
2016-09-20 10:12                                   ` Felipe Balbi
2016-09-20 12:53                                     ` Felipe Balbi
2016-09-20 14:40                                     ` Alan Stern
2017-01-16 11:12                                       ` Felipe Balbi
2017-01-16 17:09                                         ` Alan Stern
2017-01-16 19:04                                           ` Felipe Balbi
2017-01-16 19:19                                             ` Felipe Balbi
2016-09-02 19:18 ` Peter Zijlstra
2016-09-02 20:16   ` Alan Stern
2016-09-02 22:14     ` Peter Zijlstra
2016-09-02 22:16       ` Peter Zijlstra
2016-09-05  9:43         ` Will Deacon
2016-09-06 11:10           ` Peter Zijlstra
2016-09-02 22:16     ` Peter Zijlstra
2016-09-03  6:58       ` Felipe Balbi
2016-09-03 12:19         ` Peter Zijlstra
2016-09-03 13:51           ` Felipe Balbi
2016-09-05  8:09             ` Peter Zijlstra
2016-09-03 14:16           ` Alan Stern
2016-09-05  8:08             ` Peter Zijlstra [this message]
2016-09-05 14:33               ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160905080836.GV10153@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=felipe.balbi@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.