Re: Memory barrier needed with wake_up_process()?

[Alan Stern]

On Mon, 5 Sep 2016, Peter Zijlstra wrote:

> > 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.

I really don't remember.  Felipe says that the ancient history shows
the initial implementation did use a wait-queue, and then it was
changed.  Perhaps I was imitating the structure of
scsi_error_handler().

> > 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.

As mentioned later on, "CPU0" is actually a DMA master, not another 
CPU.

Alan Stern