Re: [PATCH 0/2] Patches to chapter Deferred Processing

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Thu, Jun 08, 2017 at 11:16:31AM +0800, Junchang Wang wrote:
> Hi Paul and list,
> 
> Attached are two patches for routetorture.h. Please take a look.

Good catches, queued and pushed, thank you!

> One of my remaining question is about the two smp_mb() in routetorture.h. Take
> the smp_mb() in perftest() as example, my understanding is that it is used to
> prevent the access to nthreads_running and access to goflag from being
> reorganized. If that's the case, don't we need a paired memory barrier
> instruction in perftest_reader()? Specifically, in between line 105
> (atomic_inc(&nthreads_running);) and line 106 (gf = READ_ONCE(goflag);). 

This one is unusual.  The ordering controls not correctness, but
time duration.  Plus the assignment of GOFLAG_RUN to goflag cannot
happen until after the effect of the atomic_inc() propagates back.
Interestingly enough, this code does fully not take control dependencies
into account, which could reduce the number of memory barriers.

In short, this situation is unusual and makes complex reliance on
implicit ordering guarantees.

But it might well have bugs.  If you have time, one
approach would be to read https://lwn.net/Articles/718628/ and
https://lwn.net/Articles/720550/, download the tool described, and try
to create the corresponding litmus test.  Either way, please let me know
your intentions.  This would be a really cool way for you to learn the
latest and greatest stuff about the Linux kernel memory model!

> Another puzzle is that we are using shared memory 'pap' to transfer statistic
> results from working threads, e.g. perftest_reader, to main thread, e.g.
> perftest. Do we need a smp_mb() at the tail (before instruction return) of
> function perftest_reader to force the results being written before the thread
> terminates? In other words, I'm not sure if the two events, writing to shared
> memory pap and thread termination, could be reordered.  Hints are welcome!

The pthread_create() system call guarantees that the child will see
all of the parent's memory accesses that precede the pthread_create().
Similarly, the pthread_join() system call guarantees that the parent's
accesses following the pthread_join() will see all of the (now terminated)
child's accesses.

							Thanx, Paul

> Thanks,
> --Jason
> 
> Junchang Wang (2):
>   Fix typos in help messages
>   routetorture.h: Switch from ACCESS_ONCE() to READ_ONCE()/WRITE_ONCE()
> 
>  CodeSamples/defer/routetorture.h | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> -- 
> 2.7.4
>