On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
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?
Yes, that's correct.
What this *actually* means is that you want the media player to have
higher priority than the DVD ripping program. Ergo you should run
"nice +20 my_dvd_burner" or "nice +20 my_vorbis_encoder" under CFS or
other fair schedulers. (Although you might not need to nice the dvd
burner) The key difference is this:
With the older scheduler your DVD ripping process would have had
buffer underrun problems; even though it doesn't require much CPU at
all (and can slow down burning if it doesn't get enough) it wouldn't
get a chance to run at appropriate times to keep the buffer full. If
you were encoding vorbis files you would *definitely* want to renice
it as it will consume all available CPU.
With CFS, your HD video player would get the 70% of the CPU that it
needs (exactly), and the rest would be allocated to the DVD ripper
and other processes. In addition, the DVD ripper gets certain
latency guarantees even though it's *LOWER* priority than the media
player (which also gets latency guarantees).
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?
Well, typically your video player *doesn't* chew up all of the CPU,
so the fairness helps. Here's another scenario for you: You are
running un-niced HD video player and recoding processes side-by-side,
so that the HD video player only gets 50% of the CPU. Under older
schedulers the video player would not get uniformly allocated CPU, it
would get it in fits and spurts, causing more _visibly_dropped_
frames (IE: render 30 frames, drop 8, render 15, drop 2, etc). Under
the new CFS scheduler it will get evenly allocated CPU and so while
you *will* get dropped frames, they will be less visible (IE: Render
7 frames, drop 1, render 7 frames, drop 1, render 7 frames, drop 1).
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.
Basically you are telling the kernel that your video player is no
more important than your re-encoder process which, judging by your
email, is completely untrue. If you really want it to treat the
video player as specially important (or alternatively treat the
reencoder process and specially unimportant) then you must tell it so
with "nice" or "renice".
My conclusion is that SD behaves as expected: it's more fair. But
for a desktop, shouldn't an "intelligently unfair" scheduler be
better?
Well, it is "intelligently unfair", but you the user have to tell it
what is more important for *YOU*. If I _really_ have to get some
music recoded quickly then I may be willing to deal with some dropped
frames in order to let that happen appropriately.
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?
That kind of load is boring precisely because it doesn't care about
interactivity. CFS/SD aren't a whole lot different from mainline-
without-interactivity in that respect, precisely because the latency
of the network is between ten and a hundred times more than the
latency of the scheduler. The only time it really matters is with
desktops where users care about smoothness.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
