Re: [PATCH 6/24] make atomic_read() behave consistently on frv

Chris Snook wrote:

David Howells wrote:

quoted

Chris Snook [off-list ref] wrote:

quoted

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.