Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Wed, 6 Dec 2006, Christoph Lameter wrote:
> 
> > For CPUs with load locked + store conditional, it is expensive.
> 
> Because it locks the bus? I am not that familiar with those architectures 
> but it seems that those will have a general problem anyways.

load_locked + store_conditional should _not_ be any more expensive than 
any atomic sequence will always be.

Atomic sequences in SMP are obviously never "cheap". But cmpxchg shouldn't 
be any more expensive than any other atomic sequence if you have 
load-locked and store-conditional.

There are obviously _implementation_ bugs. The early alpha's had such an 
atrocious ldl/stc that it wasn't even funny. That might be true in other 
implementations too, but it's definitely not cmpxchg-specific if so. It 
will affect _any_ atomic ops on such an architecture (atomic_inc() and 
friends)

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux