Please note that this engineer only receives memory subsystem patches and thus
please include my email on responses.
Please note that this proposal is from this engineer.
This also fulfills any legal notification of work done, but not submitted.
Notification & Proposal of Feasibility to Support System V Release 4
Defacto Standard Scheduling Extensions, etc within Linux
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.
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?
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
UNIX / Linux scheduling has in the most part attempt to achieve
some level of process / task scheduling fairness with Linux using the fair
share scheduling class. Exceptions do exist, but are not being discussed below.
In general this type of scheduling is acceptable in a generic implementation,
but has weaknesses when UNIX / Linux is moved into a different environment.
Many companies use UNIX / Linux in heavy networking environments where one or
more tasks can infrequently attempt to consume more than its fair share.
This proposal is to acknowledge that “nice” and a few other
scheduling workarounds do no always suffice to allow this temporary inequality
to exist. Yes, a cpumask could be set that allows only certain tasks to run on
specific nodes, however the implied assumption is that they only infrequently
need to have inequality / greater “time slice” than their fair share. A network
protocol example is a convergence task that needs to run until it is finished
and until that happens needed routing changes will not occur. The time window
in which all tasks need to be run, SHOULD not need this task in consecutive
time windows, thus over longer periods of time, it still fulfills the fair
scheduling policy. Again the proper CAPABILITY needs to be specified with the
priocntl(1) like application as running many tasks per CPU COULD then effect
the performance of the system.
Thus, explicit support for a new SCHED_UNFAIR scheduling policy
is proposed / suggested within the Linux kernel. Again it can be a sub
scheduling policy of SCHED_NORMAL.
Thank you,
Mitchell Erblich
UNIX Kernel Engineer
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
