[lkml]   [2009]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH][RFC]: mutex: adaptive spin

    On Tue, 6 Jan 2009, Linus Torvalds wrote:
    > So it should be renamed. Something like "task_is_oncpu()" or whatever.

    Another complaint, which is tangentially related in that it actually
    concerns "current".

    Right now, if some process deadlocks on a mutex, we get hung process, but
    with a nice backtrace and hopefully other things (that don't need that
    lock) still continue to work.

    But if I read it correctly, the adaptive spin code will instead just hang.
    Exactly because "task_is_current()" will also trigger for that case, and
    now you get an infinite loop, with the process spinning until it looses
    its own CPU, which obviously will never happen.

    Yes, this is the behavior we get with spinlocks too, and yes, lock
    debugging will talk about it, but it's a regression. We've historically
    had a _lot_ more bad deadlocks on mutexes than we have had on spinlocks,
    exactly because mutexes can be held over much more complex code. So
    regressing on it and making it less debuggable is bad.

    IOW, if we do this, then I think we need a

    BUG_ON(task == owner);

    in the waiting slow-path. I realize the test already exists for the DEBUG
    case, but I think we just want it even for production kernels. Especially
    since we'd only ever need it in the slow-path.


     \ /
      Last update: 2009-01-06 17:45    [W:0.021 / U:5.540 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site