Re: Linux Kernel Scheduling Addition Notification : Hybrid Sleepers and Unfair scheduling

[Mike Galbraith <umgwanakikbuti@gmail.com>]

On Wed, 2015-03-18 at 16:25 -0700, Mitchell Erblich wrote:

> 
> SCHED_IA
> 	Over 10 years ago, System V Release 4 was enhanced with additional
> features by Sun Microsystems. One of the more minor extensions dealt
> with the subdivision of process’s scheduling characteristics and was
> known as he INTERACTIVE /IA scheduling class. This scheduling class
> was targeted to frequent sleepers, with the mouse icon being one the
> first processes/tasks..
> 
> 	Linux has no explicit SCHED_IA scheduling policy, but does alter
> scheduling characteristics based on some sleep behavior (example:
> GENTLE_FAIR_SLEEPERS) within the fair share scheduling configuration
> option.

That's about fairness, it levels the playing field sleepers vs hogs.

>  Processes / tasks that are CPU bound that fit into a SLEEPER behavior
> can have a hybrid behavior over time where during any one scheduling
> period, it may consume its variable length allocated time. This can
> alter its expected short latency to be current / ONPROC. To simplify
> the implementation, it is suggested that SCHED_IA be a sub scheduling
> policy of SCHED_NORMAL. Shouldn’t an administrator be able to classify
> that the NORMAL long term behavior of a task, be one as a FIXED
> sleeper?

Nope, we definitely don't want a SCHED_IA class.

Your box can't tell if you're interacting or not even if you explicitly
define something as 'interactive'.  If I stare in fascination at an
eye-candy screen-saver, it becomes 'interactive'.  If I'm twiddling my
thumbs waiting for a kbuild whatever other CPU intensive job to finish,
that job becomes the 'interactive' thing of import.  The last thing I
want is to have to squabble with every crack-head programmer on the
planet who thinks his/her cool app should get special treatment.

You can't get there from here.
> 
> 	Thus, the first Proposal is to explicitly support the SCHED_IA
> scheduling policy within the Linux kernel. After kernel support, any
> application that has the same functionality as priocntl(1) then needs
> to be altered to support this new scheduling policy.
> 
> 
> Note: Administrator in this context should be a task with a UID, EUID,
> GID, EGID, etc, that has the proper CAPABILITY to alter scheduling
> behavior.

> 
> SCHED_UNFAIR

Snip.. we already have truckloads of bandwidth control.

	-Mike