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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
