[lkml]   [2010]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 1/3] Create spin lock/spin unlock with distinct memory barrier
    On Mon, 2010-02-01 at 07:22 -0800, Linus Torvalds wrote:

    > If you need other smp barriers at the lock, then what about the non-locked
    > accesses _while_ the lock is held? You get no ordering guarantees there.
    > The whole thing sounds highly dubious.

    The issues is not about protecting data, it was all about ordering an
    update of a variable (mm_cpumask) with respect to scheduling. The lock
    was just a convenient place to add this protection. The memory barriers
    here would allow the syscall to use memory barriers instead of locks.

    > And all of this for something that is a new system call that nobody
    > actually uses? To optimize the new and experimental path with some insane
    > lockfree model, while making the core kernel more complex? A _very_
    > strong NAK from me.

    I totally agree with this. The updates here were from the fear of
    grabbing all rq spinlocks (one at a time) called by a syscall would open
    up a DoS (or as Nick said RoS - Reduction of Service). If someone called
    this syscall within a while(1) loop on some large # CPU box, it could
    cause cache thrashing.

    But this is all being paranoid, and not worth the complexity in the core
    scheduler. We don't even know if this fear is founded.

    -- Steve

     \ /
      Last update: 2010-02-01 16:45    [W:0.019 / U:4.384 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site