[lkml]   [2007]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: Network slowdown due to CFS

    > > I think the real fix would be for iperf to use blocking network IO
    > > though, or maybe to use a POSIX mutex or POSIX semaphores.
    > So it's definitely not a bug in the kernel, only in iperf?


    Actually, in this case I think iperf is doing the right thing (though not
    the best thing) and the kernel is doing the wrong thing. It's calling
    'sched_yield' to ensure that every other thread gets a chance to run before
    the current thread runs again. CFS is not doing that, allowing the yielding
    thread to hog the CPU to the exclusion of the other threads. (It can allow
    the yielding thread to hog the CPU, of course, just not to the exclusion of
    other threads.)

    It's still better to use some kind of rational synchronization primitive
    (like mutex/sempahore) so that the other threads can tell you when there's
    something for you to do. It's still better to use blocking network IO, so
    the kernel will let you know exactly when to try I/O and your dynamic
    priority can rise.


    Can you clarify what CFS' current default sched_yield implementation is and
    what setting sched_compat_yield to 1 does? Which way do we get the right
    semantics (all threads of equal static priority are scheduled, with some
    possible SMP fuzziness, before this thread is scheduled again)?


    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-09-26 14:03    [W:0.023 / U:14.028 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site