Re: [PATCH] advsync: Fix store-buffering sequence table

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

On Thu, Jul 06, 2017 at 07:40:45AM +0900, Akira Yokosawa wrote:
> On 2017/07/06 7:32, Paul E. McKenney wrote:
> > On Thu, Jul 06, 2017 at 07:15:24AM +0900, Akira Yokosawa wrote:
> >> On 2017/07/05 10:32:49 -0700, Paul E. McKenney wrote:
> > 
> > [ . . . ]
> > 
> >>>>> So I cannot go with "volatile", but let's see if I can do something
> >>>>> better than the gcc intrinsics.
> >>>>
> >>>> And if the litmus7 guys don't have anything for me, I can always write a
> >>>> script to do the conversions.  So either way, we will have kernel-style
> >>>> notation at some point.  ;-)
> >>>
> >>> And it turns out that the contents of a second "{}" in a litmus7 test
> >>> is pulled directly into the output code, so an easy change.  ;-)
> >>
> >> Good news!
> >>
> >> So __atomic_thread_fence() will also be replaced with smp_mb() in
> >> the litmus tests? That will reduce the width of the tables and eliminate
> >> the need for the hspece adjustments in one-column layout.
> > 
> > Oops, I forgot to push!  Done now.
> > 
> > And yes, there is now smp_mb() in the litmus tests and the tables.
> 
> I'll take a look later.
> As I mentioned earlier, __atomic_load_n() and __atomic_store_n() seem
> to have fairly large overheads (on x86). You might want to see the changes
> in the resulting statistics and reflect them in the text.

I am getting a fair amount of variance on the results, and thus a
fair amount of overlap in the number of times each scenario shows up.
Perhaps I should say that and also state that different hardware will
likely get different results?

							Thanx, Paul