linux-kernel - Re: Question about fair schedulers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 23 Jun 2007 05:28:18 -0400
From:	"Russell Harmon" <eatnumber1@...il.com>
To:	"Alberto Gonzalez" <info@...bu.es>
Cc:	linux-kernel@...r.kernel.org
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/