[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SMP, barriers, etc.
From: |
Da Zheng |
Subject: |
Re: SMP, barriers, etc. |
Date: |
Mon, 28 Dec 2009 19:15:16 +0800 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 |
On 09-12-28 上午11:00, Samuel Thibault wrote:
> Da Zheng, le Mon 28 Dec 2009 10:31:26 +0800, a écrit :
>> On 09-12-27 下午6:38, Samuel Thibault wrote:
>>> Da Zheng, le Sun 27 Dec 2009 16:39:04 +0800, a écrit :
>>>> Is the process above correct?
>>>
>>> I have never actually programmed the architectures where things work
>>> like this (powerpc & such), but that's what I have understood from the
>>> code and explanations here and there, yes. It's a sort of transactional
>>> memory actually.
>> I just think if it's a bit too expensive that a processor has to monitor
>> other
>> processors' cache even though it's only one address.
>
> It's not more expensive than usual operations: it already has to do it
> to process cache line invalidations for everything that is in the cache.
I don't understand. Do you mean processing cache line invalidation in local
cache?
>
>> That conditional store instruction needs to do more if it succeeds. It has to
>> invalidate cache lines specified by the monitored address in other
>> processors.
>
> Locked operations on Intel have to do the same :)
Doesn't the intel processor maintain cache coherency by hardware? All
instructions that modify memory should invalidate relevant cache lines in other
processor.
>
>> Now it seems to me that the memory barrier is only to ensure that the
>> processor
>> executes instructions in the order we want.
>
> Not only that, but also as a clobber for the compiler. Note however
> that atomic_add doesn't have it, and I believe it could be dropped for
> add_return too. In Linux, atomic.h operations do _not_ necessarily
atomic_add_return can be used for implementing something like locks, so the
clobber for the compiler cannot be dropped.
>> But the data dependency barrier
>> seems to imply cache coherency according to
>> linux/Documentation/memory-barriers.txt.
>
> Err, there is _some_ cache coherency introduced by dependency barriers,
> yes.
>
>> A bit confused:-(
>
> By what?
I'm confused by whether memory barrier instructions imply cache coherency.
The memory model usually says all other cache lines can be updated *eventually*.
It doesn't say that memory barrier instructions can update cache lines in other
processors. So does the data dependency barrier invalidate all out-of-date cache
lines in the local processor?
Zheng Da
- Re: What would it take...., (continued)
- Re: What would it take...., Da Zheng, 2009/12/23
- Re: What would it take...., Samuel Thibault, 2009/12/23
- Re: What would it take...., Da Zheng, 2009/12/23
- SMP, barriers, etc., Samuel Thibault, 2009/12/23
- Re: SMP, barriers, etc., Da Zheng, 2009/12/26
- Re: SMP, barriers, etc., Samuel Thibault, 2009/12/26
- Re: SMP, barriers, etc., Da Zheng, 2009/12/27
- Re: SMP, barriers, etc., Samuel Thibault, 2009/12/27
- Re: SMP, barriers, etc., Da Zheng, 2009/12/27
- Re: SMP, barriers, etc., Samuel Thibault, 2009/12/27
- Re: SMP, barriers, etc.,
Da Zheng <=
- Re: SMP, barriers, etc., Samuel Thibault, 2009/12/28
- Re: SMP, barriers, etc., Da Zheng, 2009/12/28
- Re: SMP, barriers, etc., Samuel Thibault, 2009/12/28
Re: What would it take...., olafBuddenhagen, 2009/12/23