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
--
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
