Re: Why Semaphore Hardware-Dependent?

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

 



Nick Piggin <[email protected]> wrote:

> I wonder if we can just start with the nice powerpc code that uses
> atomic_add_return and cmpxchg (should use atomic_cmpxchg)

Because i386 (and x86_64) can do better by using XADDL/XADDQ.

The problem with CMPXCHG is that it might fail and you might have to attempt
it again.  This may be unlikely - it depends on the circumstances.  The same
applies to LL/ST equivalents.

On i386, CMPXCHG also ties you to what registers you may use for what to some
extent.  OTOH, whilst XADD does less so, the slowpath function does instead,
though with the XADD version, we can make sure that the semaphore address is
in EAX, something we can't do with CMPXCHG.

For those archs where CMPXCHG is the best available, a better algorithm than
the XADD based one is available, though I haven't submitted it.  I may still
have the patch somewhere.

However!  If what you have is LL/ST equivalents than emulating CMPXCHG to
emulate the XADD algorithm probably isn't the most optimal way either.  Don't
get stuck on using LL/ST to emulate what other CPUs have available.

> and chuck out the "crappy" rwsem fallback implementation,

CMPXCHG is not available on all archs, and may not be implemented on all archs
through other atomic instructions.

> as well as all the arch specific code?

Using CMPXCHG is only optimal where that's the best available.

David
-
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