On Wed, May 25, 2011 at 4:54 PM, Andrew Haley <a...@redhat.com> wrote:
> On 05/25/2011 03:47 PM, H.J. Lu wrote:
>> On Wed, May 25, 2011 at 7:36 AM, Andrew Haley <a...@redhat.com> wrote:
>>> On 05/25/2011 01:34 PM, H.J. Lu wrote:
>>>> On Wed, May 25, 2011 at 3:26 AM, Andrew Haley <a...@redhat.com> wrote:
>>>>> On 05/24/2011 07:28 PM, H.J. Lu wrote:
>>>>>
>>>>>> This patch implements pause intrinsic suggested by Andi. OK
>>>>>> for trunk?
>>>>>
>>>>> What does "full memory barrier" here mean?
>>>>>
>>>>> +@table @code
>>>>> +@item void __builtin_ia32_pause (void)
>>>>> +Generates the @code{pause} machine instruction with full memory barrier.
>>>>> +@end table
>>>>>
>>>>> There a memory clobber, but no barrier instruction AFAICS. The
>>>>> doc needs to explain it a bit better.
>>>>
>>>> There are read/load memory barrier, write/store memory barrier and
>>>> full/general
>>>> memory barrier. You can find them at
>>>>
>>>> http://www.kernel.org/doc/Documentation/memory-barriers.txt
>>>>
>>>> Should I include a pointer to it?
>>>
>>> No. I know perfectly well what memory barriers are. I'm not asking
>>> what "full memory barrier" means.
>>>
>>> What barrier instruction(s) does __builtin_ia32_pause() generate?
>>> All I see in the patch is "rep; nop". Is that really a full memory
>>> barrier?
>>
>> It is a full memory barrier in the sense that compiler won't move
>> load/store across it. It is intended for kernel.
>
> Right, so it is, in fact, not a full memory barrier. I thought not.
> I's no more a full memory barrier than a simple asm volatile("") .
> The doc needs to explain that a bit better.
asm volatile ("" : : : "memory") in fact will work as a full memory barrier
because we are very very lazy in disambiguating against asms
(but that should change, at least a tiny bit). Function calls otoh are
pretty well optimized.
Richard.
> Andrew.
>
