On Jun 23, 2007, at 03:46:43, Alberto Gonzalez wrote:
On Saturday 23 June 2007, Kyle Moffett wrote:
On Jun 22, 2007, at 18:07:15, Alberto Gonzalez wrote:
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.
Ok, that makes sense. The problem is that desktop users don't know
about such things, so the ideal situation would be that the
scheduler knows about it and does it for you.
No, it is *categorically* *impossible* for the scheduler to get that
decision right. For example, if my job is as a programmer and I'm
waiting for a build during lunchbreak then I may not care that the
process in the background makes my DVD-player drop a few frames, as
long as it gets done 10% quicker. That kind of decision is *POLICY*,
and it does not belong in the kernel. If you want the kernel to
treat one job or the other as more important then you must *TELL* it
that, end of story.
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).
Yes, I see your point. In a scenario of dropping frames it seems
that CFS does a better job. It's just that an ideal scheduler
shouldn't drop frames in this case (it should give 70% to the video
even without nicing the encoder).
It can't do that. The with-CFS kernel just sees 2 CPU-heavy
processes and guesses that it should give them equal CPU. "stock"
kernels have an algorithm designed to promote some tasks for
"interactivity", but in practice it also tended to cause other
processes to be denied CPU for arbitrarily long periods of time,
hence why CFS is an improvement. Under the old scheduler even if you
had 2 DVD player processes each chewing 45% CPU, you could still have
dropped frames because for a second or two one would be more
"interactive" than the other, and vice versa. Under CFS/SD, they are
both classified equally and so get equal CPU allocation *AND* latency.
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".
That's my whole point. On a desktop, some tasks have by nature a
higher priority than others. A fair scheduler treats them all the
same (hence, fair) way. So a user must nice/renice processes for
them to get the correct CPU time (something you can't expect normal
desktop users to do).
I don't see any reason someone couldn't write a simple little GUI
program to enumerate the user-owned X processes (somewhat like the
Windows Task-Manager but less complicated) and allow them to change
priorities. Alternatively your desktop environment could set up a
little privileged wrapper which appropriately executes the HD video
player. One of the primary rules of kernel development is that you
cannot put policy in the kernel, and a statement of the form
"PROCESS1 is more important than PROCESS2" is pure policy and must be
done from userspace. We even give appropriate enforcement mechanisms
to userspace to take such action (nice levels).
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]
