On Mon, Oct 12, 2015 at 01:54:38PM +0200, Peter Zijlstra wrote: > On Mon, Oct 12, 2015 at 05:06:36PM +0800, Boqun Feng wrote: > > Understood. > > > > But, IMO, the position of this section is already misleading: > > > > (*) Implicit kernel memory barriers. > > - Locking functions. > > - Interrupt disabling functions. > > ->- Sleep and wake-up functions.<- > > - Miscellaneous functions. > > > > I read it as that sleep and wake-up functions provide some kernel memory > > barriers which we can use *externally*(outside sleep/wakeup themselves). > > I think it is useful to state that the primitives handle the ordering > between the waker and wakee wrt the 'blocking' state. > I agree that's useful, however, the 'blocking' state is something internal for sleep and wakeup, right? Not sure whether the users of wake_up() and wait_event() will care much about this or they need to understand that detailedly to use wake_up() and wait_event() correctly. I treat this part of memory-barriers.txt as an API document to describe the implicit barriers in some primitives, which can be used *externally* by someone, but anyway, that's just my own opinion ;-) > But I've not put much thought into wording. I wanted to finish process > order 'comment' patch first. Of course. Actually your 'comment' patch is the reason why I think this section may be removed. Regards, Boqun
Attachment:
signature.asc
Description: PGP signature
