On 2017/07/09 12:26:55 -0700, Paul E. McKenney wrote:
> On Sun, Jul 09, 2017 at 10:39:46AM +0900, Akira Yokosawa wrote:
>> >From 955eefe8ad5a64fddd2e33b343ac3a1e171dd089 Mon Sep 17 00:00:00 2001
>> From: Akira Yokosawa <akiyks@xxxxxxxxx>
>> Date: Sun, 9 Jul 2017 09:53:28 +0900
>> Subject: [PATCH 0/2] litmus test updates
>>
>> Hi Paul,
>>
>> I thought that embedding kernel API definitions in each litmus test is
>> redundant. We can use #include instead. In this case, we need to
>> specify a -I option for gcc as the compilation is done in a temporally
>> directory. We can do so by using -ccopts option of litmus7.
>>
>> Patch 1 does this change.
>
> You know, I tried this and it kept complaining about not finding the
> include file. No idea what I was doing wrong, but whatever it was,
> thank you very much for getting it right!!!
>
>> However, in native run on x86_64, I'm seeing a significant difference
>> in the resulting statistics.
>> Before the change, a typical result is:
>>
>> Test C-SB+o-o+o-o Allowed
>> Histogram (4 states)
>> 54 *>0:r2=0; 1:r2=0;
>> 49999628:>0:r2=2; 1:r2=0;
>> 49999697:>0:r2=0; 1:r2=2;
>> 621 :>0:r2=2; 1:r2=2;
>> Ok
>>
>> After the change, the result is something like:
>>
>> Test C-SB+o-o+o-o Allowed
>> Histogram (4 states)
>> 26 *>0:r2=0; 1:r2=0;
>> 49999782:>0:r2=2; 1:r2=0;
>> 49999818:>0:r2=0; 1:r2=2;
>> 374 :>0:r2=2; 1:r2=2;
>> Ok
>>
>> In cross compilation mode, the result is similar and consistent
>> with the native run after the change.
>> So I suspect litmus7's behavior of native run is affected by the
>> "-ccopts" option. Again, this might depend on the platform variation.
>
> Between differences in compilers, compiler options, and hardware,
> we should expect quite a bit of of variation. In fact, there are
> sometimes specific pieces of hardware that have much stronger
> memory ordering than the architecture guarantees.
>
>> Patch 2 adds targets for cross compilation mode of litmus7.
>> Because we need to copy the custom header file "api.h" into the target
>> directory, I made the recipe to do so.
>
> Looks good!
>
>> I stopped short of adding recipes to make an archive and scp it to
>> remote host and to do remote compilation and execution via ssh.
>> They can be added later.
>
> Your choice on this one. ;-)
>
>> On PPC, the result of C-SB+o-o+o-o.litmus looks interesting.
>> (Of course, you are familiar with PPC, but...)
>>
>> Test C-SB+o-o+o-o Allowed
>> Histogram (4 states)
>> 988335*>0:r2=0; 1:r2=0;
>> 49516879:>0:r2=2; 1:r2=0;
>> 49494779:>0:r2=0; 1:r2=2;
>> 7 :>0:r2=2; 1:r2=2;
>> Ok
>
> I am not surprised by this. PPC tends to do more local processing for
> longer than x86 does, as an extremely rough rule of thumb. PPC's weak
> ordering enables this. So getting the outcome where both CPUs communicate
> with each other should be harder on PPC than on x86.
>
>> Witnesses
>> Positive: 988335, Negative: 99011665
>> Condition exists (1:r2=0 /\ 0:r2=0) is validated
>> Hash=9bb70a6ed845b4be5f335c7eeb134f3f
>>
>> Note that I've not tested the result of "cross-arm" target actually
>> builds and runs on ARM hosts.
>
> There are supposed to be places to get free access to ARM hardware.
> If you don't find one, let me know, and I will be happy to reach out
> to my contacts at ARM and Linaro.
Well, I tried Linaro Developer Cloud, but they are not accepting
requests of new instances. The request page says:
> Capacity reached
> Due to the very high levels of interest in Developer Cloud, we have
> temporarily reached our capacity limits. We are in the process of
> expanding our service but, in the meantime, we are currently not able
> to accept any more requests for instances. Once capacity is available
> again, the "Request Cloud Instance" option will be available again.
So I'm waiting the capacity to become available.
Are you aware of an alternative service?
BTW, I managed to have a (sporadic) access to an ARMv8 host yesterday.
I tried the result of "cross-arm" target, and it worked just fine.
However, "make" in other CodeSamples' sub-directories didn't go well,
I'm attempting to add support for arm64. If it works, I'll submit
a patch set.
Thanks, Akira
>> How does this approach look like?
>
> Quite nice! I queued and pushed it, again, thank you!
>
> Thanx, Paul
>
>> Thanks, Akira
>> --
>> Akira Yokosawa (2):
>> advsync: Use '#include "api.h"' in litmus tests
>> advsync: Add cross compilation targets
>>
>> CodeSamples/advsync/herd/.gitignore | 5 ++++
>> CodeSamples/advsync/herd/C-SB+o-mb-o+o-mb-o.litmus | 4 +--
>> CodeSamples/advsync/herd/C-SB+o-o+o-o.litmus | 3 +-
>> CodeSamples/advsync/herd/Makefile | 34 ++++++++++++++++++++--
>> CodeSamples/advsync/herd/api.h | 8 +++++
>> 5 files changed, 47 insertions(+), 7 deletions(-)
>> create mode 100644 CodeSamples/advsync/herd/api.h
>>
>> --
>> 2.7.4
>>
>
>
--
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
