Re: i386 spinlock fairness: bizarre test results

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 10/11/05

  • Next message: Justin R. Smith: "Clock stopping (was Instability in kernel version 2.6.12.5)"
    Date:	Tue, 11 Oct 2005 07:44:43 -0700 (PDT)
    To: Alan Cox <alan@lxorguk.ukuu.org.uk>
    
    

    On Tue, 11 Oct 2005, Alan Cox wrote:

    > On Maw, 2005-10-11 at 00:04 -0400, Chuck Ebbert wrote:
    > > That test machine was a dual 350MHz Pentium II Xeon; on a dual 333MHz Pentium II
    > > Overdrive (with very slow Socket 8 bus) I could not reproduce those results.
    > > However, on that machine the 'xchg' instruction made the test run almost 20%
    > > _faster_ than using 'mov'.
    > >
    > > So I think the i386 spinlock code should be changed to always use 'xchg' to do
    > > spin_unlock.
    >
    >
    > Using xchg on the spin unlock path is expensive. Really expensive on P4
    > compared to movb. It also doesn't guarantee anything either way around
    > especially as you go to four cores or change CPU (or in some cases quite
    > likely even chipset).

    Indeed.

    I suspect that the behaviour Chuck saw is (a) only present under
    contention and (b) very much dependent on other timing issues.

    (a) is the wrong thing to optimize for, and (b) means that Chuck's numbers
    aren't reliable anyway (as shown by the fact that things like instruction
    alignment matters, and by Eric's numbers on other machines).

    We want the spinlocks to behave well when they are _not_ under heavy
    contention. If a spinlock gets so much contention that it starts having
    these kinds of issues, then there's something wrong at higher levels, and
    the fix is to use a different algorithm, or use a different kind of lock.

    Spinlocks by definition are the _simplest_ locks there are. Not the
    smartest or most fair. Trying to make them anything else is kind of
    missing the whole point of them.

                            Linus
    -
    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/


  • Next message: Justin R. Smith: "Clock stopping (was Instability in kernel version 2.6.12.5)"

    Relevant Pages

    • Re: RT patch acceptance
      ... although it probably doesnt need full semaphore ... > And maybe some of the heavier spinlocks. ... be submitted upstream if so desired with no associated lock changes. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: [PATCH] Yielding processor resources during lock contention
      ... >clear that it's a good idea using it for things like spinlocks. ... >fact that it just released the lock. ... >very high latencies. ... It could make spinlock contention very very unfair ...
      (Linux-Kernel)
    • Re: FUSYN and RT
      ... but he has turned all spinlocks into ... > This lock is only held to protect access to the queues. ... The choice of lock type should derive from both the calling ... 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/ ...
      (Linux-Kernel)
    • Re: Question from Russells Spinlocks
      ... Spinlocks are used in cases where the operation performed under a lock is short one - takes very less time. ... So if we take out CPU-B from the above equation - there is no chance for Thread B to execute to contend for lock L1 without thread A going to sleep. ... > like disable interrupts and premptations. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: SMP syncronization on AMD processors (broken?)
      ... > uses spinlocks without any problematic restart. ... drop a lock in the expectation that another CPU will acquire it and get us ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)