Re: SMP syncronization on AMD processors (broken?)

From: Andrey Savochkin (saw_at_sawoct.com)
Date: 10/06/05

  • Next message: Hugh Dickins: "Re: SMP syncronization on AMD processors (broken?)" 
    Date:	Thu, 6 Oct 2005 19:21:06 +0400
To: Linus Torvalds <torvalds@osdl.org>

    On Thu, Oct 06, 2005 at 07:52:17AM -0700, Linus Torvalds wrote:
    >
    >
    > On Thu, 6 Oct 2005, Andrey Savochkin wrote:
    > >
    > > Well, it's hard to swallow...
    > > It's not about being not fully fair, it's about deadlocks that started
    > > to appear after code changes inside retry loops...
    >
    > No, it's not about fairness.
    >
    > It's about BUGS IN YOUR CODE.
    >
    > If you need fairness, you need to implement that yourself. You can do so
    > many ways. Either on top of spinlocks, by using an external side-band
    > channel, or by using semaphores instead of spinlocks (semaphores are much
    > higher cost, but part of the cost is that they _are_ fair).

    Ok, let it be a bug.

    I just want to repeat that nobody wanted or expected any fairness in this case.
    But such extremety that on some CPU models one CPU never, not in billion
    cycles, can get the lock if the other CPU repeatedly drops and acquires the
    lock, and that in this scenario memory changes seem to never propagate to
    other CPUs - well, all of that is a surprise.

    I start to wonder about existing mainstream code, presumably bug-free, that
    uses spinlocks without any problematic restart.
    If one day some piece starts to be called too often by some legitimate
    reasons, it might fall into the same pattern and completely block others who
    want to take the same spinlock.
    I'm not advocating for changing spinlock implementation, it's just a
    thought...

            Andrey
    -
    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: Hugh Dickins: "Re: SMP syncronization on AMD processors (broken?)"

    Relevant Pages

    • Re: [RFC] scheduler: improve SMP fairness in CFS
      ... Instead of an explicit system-wide fairness invariant, ... If we guarantee that the load on CPU X does not differ from the load on CPU %N by more than some small constant, then we know that the system is fairly balanced. ... the global rw_lock, and task migrations. ... I agree they can be problems on NUMA, but I'd argue they are not on SMPs. ...
      (Linux-Kernel)
    • Re: [RFC -v2 PATCH 2/3] sched: add yield_to function
      ... have the right to diddle to yield. ... since the spinner isn't accomplishing anything, ... We definitely want to maintain fairness. ... Unless the other task donates some cpu share back. ...
      (Linux-Kernel)
    • Re: [RFC] scheduler: improve SMP fairness in CFS
      ... Instead of an explicit system-wide fairness invariant, ... If we guarantee that the load on CPU X does not differ from the load on CPU %N by more than some small constant, then we know that the system is fairly balanced. ... The same is true for desktops, where users want to nice tasks and see an effect that's consistent with what they expect, i.e., task CPU time should be proportional to their nice values. ... I agree they can be problems on NUMA, but I'd argue they are not on SMPs. ...
      (Linux-Kernel)
    • Re: [RFC -v2 PATCH 2/3] sched: add yield_to function
      ... The yielding task is entitled to its fair share of the cpu, ... All we want is to boost task A, and to unboost the donor in order to maintain fairness. ... have the right to diddle to yield. ... So we want to preserve our entitlement. ...
      (Linux-Kernel)
    • Re: Buggy IPI and MTRR code on low memory
      ... With ticket spinlocks and such, ... cpu caller: ... call ipi functions ... Thus we synchronize the callers, but the callers do not need to wait on ...
      (Linux-Kernel)