2017/07/06 9:46、Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> のメッセージ:
>> 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?
>
So the reason I saw the large overhead might be the disturbance of virtual guest machine. I didn't try repeatedly after the change.
If you don't see any significant difference in the result, there is no need to modify the text.
But mentioning the possibility of fluctuations will be of help.
Sorry for the noise.
Thanks, Akira
(from mobile, might be QP encoded)
> 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
