[lkml]   [2007]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Network slowdown due to CFS
    On Mon, 1 Oct 2007 15:17:52 -0700
    "David Schwartz" <> wrote:

    > Arjan van de Ven wrote:
    > > > It can occasionally be an optimization. You may have a case where
    > > > you can do something very efficiently if a lock is not held, but
    > > > you cannot afford to wait for the lock to be released. So you
    > > > check the lock, if it's held, you yield and then check again. If
    > > > that fails, you do it the less optimal way (for example,
    > > > dispatching it to a thread that *can* afford to wait).
    > > at this point it's "use a futex" instead; once you're doing system
    > > calls you might as well use the right one for what you're trying to
    > > achieve.
    > There are two answers to this. One is that you sometimes are writing
    > POSIX code and Linux-specific optimizations don't change the fact
    > that you still need a portable implementation.
    > The other answer is that futexes don't change anything in this case.
    > In fact, in the last time I hit this, the lock was a futex on Linux.
    > Nevertheless, that doesn't change the basic issue. The lock is
    > locked, you cannot afford to wait for it, but not getting the lock is
    > expensive. The solution is to yield and check the lock again. If it's
    > still held, you dispatch to another thread, but many times, yielding
    > can avoid that.

    yielding IS blocking. Just with indeterminate fuzzyness added to it....
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-10-02 00:39    [W:0.023 / U:5.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site