[lkml]   [2007]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Network slowdown due to CFS

    * David Schwartz <> wrote:

    > > These are generic statements, but i'm _really_ interested in the
    > > specifics. Real, specific code that i can look at. The typical Linux
    > > distro consists of in execess of 500 millions of lines of code, in
    > > tens of thousands of apps, so there really must be some good, valid
    > > and "right" use of sched_yield() somewhere in there, in some
    > > mainstream app, right? (because, as you might have guessed it, in
    > > the past decade of sched_yield() existence i _have_ seen my share of
    > > sched_yield() utilizing user-space code, and at the moment i'm not
    > > really impressed by those examples.)
    > Maybe, maybe not. Even if so, it would be very difficult to find.
    > [...] is your friend. Really,

    > Note that I'm not saying this is a particularly big deal. And I'm not
    > calling CFS' behavior a regression, since it's not really better or
    > worse than the old behavior, simply different.

    yes, and that's the core point.

    > I'm not familiar enough with CFS' internals to help much on the
    > implementation, but there may be some simple compromise yield that
    > might work well enough. How about simply acting as if the task used up
    > its timeslice and scheduling the next one? (Possibly with a slight
    > reduction in penalty or reward for not really using all the time, if
    > possible?)

    firstly, there's no notion of "timeslices" in CFS. (in CFS tasks "earn"
    a right to the CPU, and that "right" is not sliced in the traditional
    sense) But we tried a conceptually similar thing: to schedule not to the
    end of the tree but into the next position. That too was bad for _some_
    apps. CFS literally cycled through 5-6 different yield implementations
    in its 22 versions so far. The current flag solution was achieved in
    such an iterative fashion and gives an acceptable solution to all app
    categories that came up so far. [ and this is driven by compatibility
    goals - regardless of how broken we consider yield use. The ideal
    solution is of course to almost never use yield. Fortunately 99%+ of
    Linux apps follow that ideal solution ;-) ]

    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 08:09    [W:0.026 / U:6.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site