From: Alberto Gonzalez <info@gnebu.es>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Question about fair schedulers
Date: Sat, 23 Jun 2007 00:07:15 +0200 [thread overview]
Message-ID: <200706230007.15622.info@gnebu.es> (raw)
Hi,
First I'd like to say I'm not a programmer or even a geek, just a normal user,
so my question might be very basic or even stupid. If so, please excuse me.
I've been reading about CFS and SD schedulers here on the list and my basic
understanding is that they try to improve interactivity by being completely
fair, i.e., giving the same amount of CPU time to each task running at a
given time. There is something I don't get about this, so today I tried a
little test with the -ck kernel comparing it to mainline.
Let's say I have a HD video that uses ~70% CPU. Let's say I want to watch it
while I encode my music to vorbis (or rip a DVD). This is the only reasonable
scenario I can imagine on a normal desktop, since most desktops have the CPU
idle or under 10% usage during 95% of the time and a CPU scheduler makes no
difference (maybe people on this list compile a few kernels every day, but
that's not what most normal users like me do).
Ok, so what will a fair scheduler do in this case? It is my understanding that
it would give 50% CPU to each task, resulting in the video dropping frames.
Is this correct?
Now, the _ideal_ solution for this situation would be to give ~70% to the
video and the rest (~30%) to the encoder. But this goes against fairness,
doesn't it? Yet most reports I've read about these two fair schedulers say
that videos play smoother under load. What am I missing?
If I ask this question is because today I tested it and found that using
the -ck kernel (with SD scheduler) the video would drop frames, while with
the mainline kernel it played fine.
My conclusion is that SD behaves as expected: it's more fair. But for a
desktop, shouldn't an "intelligently unfair" scheduler be better?
Thanks for any insights.
P.S: As a second thought, a fair scheduler could behave really good in other
scenarios, like a server running a busy forum on apache+mysql+php. Besides,
this is a more real world scenario (and easier to benchmark). Why aren't
people testing these schedulers under this kind of load?
next reply other threads:[~2007-06-22 23:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-22 22:07 Alberto Gonzalez [this message]
2007-06-23 0:55 ` Kyle Moffett
2007-06-23 7:46 ` Alberto Gonzalez
2007-06-23 16:35 ` Kyle Moffett
2007-06-23 17:28 ` Alberto Gonzalez
2007-06-24 20:57 ` Jesper Juhl
2007-06-24 19:36 ` David Schwartz
2007-06-26 12:19 ` Helge Hafting
2007-06-27 12:39 ` Alberto Gonzalez
2007-06-23 7:06 ` Paolo Ornati
2007-06-23 8:01 ` Alberto Gonzalez
2007-06-23 8:23 ` Willy Tarreau
2007-06-23 9:18 ` Alberto Gonzalez
2007-06-23 9:28 ` Russell Harmon
2007-06-23 10:30 ` Willy Tarreau
2007-06-23 10:45 ` Alberto Gonzalez
2007-06-23 10:50 ` Willy Tarreau
2007-06-23 11:00 ` Alberto Gonzalez
2007-06-23 11:05 ` Tom Spink
2007-06-23 11:26 ` Alberto Gonzalez
2007-06-23 11:51 ` Willy Tarreau
2007-06-27 20:28 ` Bill Davidsen
2007-06-23 13:26 ` Paolo Ornati
2007-06-23 13:56 ` Alberto Gonzalez
2007-06-23 14:28 ` Paolo Ornati
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=200706230007.15622.info@gnebu.es \
--to=info@gnebu.es \
--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
all inboxes | Powered by JetHome®