Re: Question about fair schedulers
From: Russell Harmon
Date: Sat Jun 23 2007 - 05:28:32 EST
I think you're not considering normal users here. Believe it or not, 99% of
desktop users in the world just click on a icon to watch a video. And they DO
want watch them, not use them for monitoring purposes (whatever that means).
I acknowledge it's impossible to be inside a user's mind to decide what it's
more important to him/her, but let's agree that clearly a audio/video player
should have by default a higher priority than an audio/video encoder, for the
simple reason that one task requires a certain amount of CPU to do the job
correctly, while the other one can do the job correctly regardless of how
much CPU time you give it. They are different in nature. What I don't know is
if knowing this should belong to the CPU scheduler or to the application
itself. But the bottom line is that on a desktop, tasks should receive
different -unfair- amounts of CPU time to work correctly. The "fair" concept
still looks wrong to me.
Nicing tasks might not be hard at all, but expecting normal users to do so is
not realistic. Either the scheduler or the applications should make these
decisions for them (us).
While I agree in principle that less work for the end user who wants
it to "just work" is good (if done correctly), I think this is more an
issue of where the scheduler is being put to work. In a desktop
environment, I'd agree that you would want the player > encoder, but
in say a video authoring machine, you would definatley want the
encoder > player. It seems to me that the best solution would be a
compile time option to configure the scheduler for the environment it
will be working in.
I do think however that the default in most cases should be "it just
works" with the option of turning on the more advanced features.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/