Messages in this thread | | | Date | Sat, 23 Jun 2007 05:28:18 -0400 | From | "Russell Harmon" <> | Subject | Re: Question about fair schedulers |
| |
> 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/
| |