Chris Snook wrote:
quoted text
> David Howells wrote:
> 
>> Chris Snook <csnook@redhat.com> wrote:
>>
>>> cpu_relax() contains a barrier, so it should do the right thing.  For 
>>> non-smp
>>> architectures, I'm concerned about interacting with interrupt 
>>> handlers.  Some
>>> drivers do use atomic_* operations.
>>
>>
>> I'm not sure that actually answers my question.  Why not smp_rmb()?
>>
>> David
> 
> 
> I would assume because we want to waste time efficiently even on non-smp 
> architectures, rather than frying the CPU or draining the battery.  
> Certain looping execution patterns can cause the CPU to operate above 
> thermal design power.  I have fans on my workstation that only ever come 
> on when running LINPACK, and that's generally memory bandwidth-bound.  
> Just imagine what happens when you're executing the same few 
> non-serializing instructions in a tight loop without ever stalling on 
> memory fetches, or being scheduled out.
> 
> If there's another reason, I'd like to hear it too, because I'm just 
> guessing here.

Well if there is only one memory location involved, then smp_rmb() isn't
going to really do anything anyway, so it would be incorrect to use it.

Consider that smp_rmb basically will do anything from flushing the
pipeline to invalidating loads speculatively executed out of order. AFAIK
it will not control the visibility of stores coming from other CPUs (that
is up to the cache coherency).

-- 
SUSE Labs, Novell Inc.
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/