On Mon, Jun 25, 2018 at 11:50:31AM +0200, Peter Zijlstra wrote: > On Mon, Jun 25, 2018 at 11:17:38AM +0200, Andrea Parri wrote: > > Both the implementation and the users' expectation [1] for the various > > wakeup primitives have evolved over time, but the documentation has not > > kept up with these changes: brings it into 2018. > > I wanted to reply to this saying that I'm not aware of anything relying > on this actually being a smp_mb() and that I've been treating it as an > RELEASE. > > But then I found my own comment that goes with smp_mb__after_spinlock(), > which explains why we do in fact need the transitive thing if I'm not > mistaken. A concrete example being the store-buffering pattern reported in [1]. > > So yes, I suppose we're entirely suck with the full memory barrier > semantics like that. But I still find it easier to think of it like a > RELEASE that pairs with the ACQUIRE of waking up, such that the task > is guaranteed to observe it's own wake condition. > > And maybe that is the thing I'm missing here. These comments only state > that it does in fact imply a full memory barrier, but do not explain > why, should it? "code (people) is relying on it" is really the only "why" I can think of. With this patch, that same/SB pattern is also reported in memory -barriers.txt. Other ideas? Andrea -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
