From: Ingo Molnar <mingo@elte.hu>
To: David Schwartz <davids@webmaster.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Network slowdown due to CFS
Date: Tue, 2 Oct 2007 08:06:07 +0200 [thread overview]
Message-ID: <20071002060607.GA18588@elte.hu> (raw)
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKOEOBHCAC.davids@webmaster.com>
* David Schwartz <davids@webmaster.com> 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.
> [...]
google.com/codesearch 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 ;-) ]
Ingo
next prev parent reply other threads:[~2007-10-02 6:06 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-26 8:52 Network slowdown due to CFS Martin Michlmayr
2007-09-26 9:34 ` Ingo Molnar
2007-09-26 9:47 ` Ingo Molnar
2007-09-26 10:08 ` Martin Michlmayr
2007-09-26 10:18 ` Ingo Molnar
2007-09-26 10:20 ` Mike Galbraith
2007-09-26 10:23 ` Mike Galbraith
2007-09-26 10:48 ` Martin Michlmayr
2007-09-26 11:21 ` Ingo Molnar
2007-09-26 11:29 ` Martin Michlmayr
2007-09-26 12:00 ` David Schwartz
2007-09-26 13:31 ` Ingo Molnar
2007-09-26 15:40 ` Stephen Hemminger
2007-09-26 15:46 ` Stephen Hemminger
2007-09-27 9:30 ` Jarek Poplawski
2007-09-27 9:46 ` Ingo Molnar
2007-09-27 12:27 ` Jarek Poplawski
2007-09-27 13:31 ` Ingo Molnar
2007-09-27 14:42 ` Jarek Poplawski
2007-09-28 6:10 ` Nick Piggin
2007-10-01 8:43 ` Jarek Poplawski
2007-10-01 16:25 ` Ingo Molnar
2007-10-01 16:49 ` David Schwartz
2007-10-01 17:31 ` Ingo Molnar
2007-10-01 18:23 ` David Schwartz
2007-10-02 6:06 ` Ingo Molnar [this message]
2007-10-02 6:47 ` Andi Kleen
2007-10-03 8:02 ` Jarek Poplawski
2007-10-03 8:16 ` Ingo Molnar
2007-10-03 8:56 ` Jarek Poplawski
2007-10-03 9:10 ` Ingo Molnar
2007-10-03 9:50 ` Jarek Poplawski
2007-10-03 10:55 ` Dmitry Adamushko
2007-10-03 10:58 ` Dmitry Adamushko
2007-10-03 11:20 ` Jarek Poplawski
2007-10-03 11:22 ` Ingo Molnar
2007-10-03 11:40 ` Jarek Poplawski
2007-10-03 11:56 ` yield Ingo Molnar
2007-10-03 12:16 ` yield Jarek Poplawski
2007-10-07 7:18 ` Network slowdown due to CFS Ingo Molnar
2007-10-04 5:33 ` Casey Dahlin
2007-10-02 6:08 ` Ingo Molnar
2007-10-02 6:26 ` Ingo Molnar
2007-10-02 6:46 ` yield API Ingo Molnar
2007-10-02 11:50 ` linux-os (Dick Johnson)
2007-10-02 15:24 ` Douglas McNaught
2007-10-02 21:57 ` Eric St-Laurent
2007-12-12 22:39 ` Jesper Juhl
2007-12-13 4:43 ` Kyle Moffett
2007-12-13 20:10 ` David Schwartz
2007-10-01 19:53 ` Network slowdown due to CFS Arjan van de Ven
2007-10-01 22:17 ` David Schwartz
2007-10-01 22:35 ` Arjan van de Ven
2007-10-01 22:44 ` David Schwartz
2007-10-01 22:55 ` Arjan van de Ven
2007-10-02 15:37 ` David Schwartz
2007-10-03 7:15 ` Jarek Poplawski
2007-10-03 11:31 ` Helge Hafting
2007-10-04 0:31 ` Rusty Russell
2007-10-01 16:55 ` Chris Friesen
2007-10-01 17:09 ` Ingo Molnar
2007-10-01 17:45 ` Chris Friesen
2007-10-01 19:09 ` iperf yield usage Ingo Molnar
2007-10-02 9:03 ` Network slowdown due to CFS Jarek Poplawski
2007-10-02 13:39 ` Jarek Poplawski
2007-10-02 9:26 ` Jarek Poplawski
2007-09-27 9:49 ` Ingo Molnar
2007-09-27 10:54 ` Martin Michlmayr
2007-09-27 10:56 ` Ingo Molnar
2007-09-27 11:12 ` Martin Michlmayr
-- strict thread matches above, loose matches on Subject: below --
2007-10-01 22:27 Hubert Tonneau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071002060607.GA18588@elte.hu \
--to=mingo@elte.hu \
--cc=davids@webmaster.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox