On Wed, Nov 01, 2017 at 12:36:13AM +0900, Akira Yokosawa wrote: > On 2017/10/30 11:14:23 -0700, Paul E. McKenney wrote: > > On Mon, Sep 18, 2017 at 07:51:29AM +0900, Akira Yokosawa wrote: > >> On 2017/09/17 14:55:08 -0700, Paul E. McKenney wrote: > >>> On Sun, Sep 17, 2017 at 08:04:21PM +0900, Akira Yokosawa wrote: > >>>> On 2017/09/16 18:07:30 -0700, Paul E. McKenney wrote: > >>>>> On Sat, Sep 16, 2017 at 08:01:45PM +0900, Akira Yokosawa wrote: [ . . . ] > >>>> Adding this example in the text might be too verbose. > >>>> Would a Quick Quiz be reasonable? > >>> > >>> Might be good in the section on protecting memory references, and putting > >>> it into a quick quiz or two makes a lot of sense. > >> > >> It's up to you where to put it. > >> > >> And I now realize using READ_ONCE() and WRITE_ONCE() is quite tricky. > >> Missing one might not cause a problem today, but a smarter compiler > >> can expose the bug in the future... > >> > >> This is scary. > > > > Section 15.3.1 is supposed to cover READ_ONCE() and WRITE_ONCE(). > > There is one final paragraph added just now, but if you get a chance, > > please let me know what you think. > > It looks OK to me. Some minor nitpicks. > > * On exact exceptions and exact interrupts: > > IIRC, I've heard from you that there is an exceptional architecture > which requires explicit memory barriers in exception/interrupt handlers. > Was it Itanium? For interrupts from kernel code, it is sometimes the case that the kernel needs other CPUs to see the accesses in the code before the interrupt handler, the code within the interrupt handler, and the code after the interrupt handler to have happened in order. In that case, the interrupt entry/exit code might well need full memory barriers. There are other ways to organize this that do not require interrupt entry/exit memory barriers, for example, the convention could be that locking be used. > * On the final paragraph of Section 15.3.1: > > "Nevertheless" appears twice in this paragraph. You might want to > reword one of them. Good point, how about the following? Nevertheless, it is quite possible to overdo use of READ_ONCE() and WRITE_ONCE(). For example, if you have prevented a given variable from changing (perhaps by holding the lock guarding all updates to that variable), there is no point in using READ_ONCE(). Similarly, if you have prevented any other CPUs or threads from reading a given variable (perhaps because you are initializing that variable before any other CPU or thread has access to it), there is no point in using WRITE_ONCE(). However, my experience is that developers need to use things like READ_ONCE() and WRITE_ONCE() more often than they think that they do, the overhead of unnecessary uses is quite low, and the penalty for failing to use them when needed is quite high. Thanx, Paul > > And if you are scared, you might actually have a good understanding > > of the true situation. ;-) > > Whew!!! > > Thanks, Akira > > > > > Thanx, Paul > > > >> Thanks, Akira > >> > >>> > >>> Thanx, Paul > >>> > >>>> Thanks, Akira > >>>> > >>>>> > >>>>> Thanx, Paul > >>>>> > >>>>> > >>>> > >>> > >>> > >> > > > > > -- To unsubscribe from this list: send the line "unsubscribe perfbook" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
