Re: Question about fair schedulers

["Russell Harmon" <eatnumber1@gmail.com>]

> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/