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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
