Proposed new Linux Scheduling Policies                                    July 
2019

Version 0.9

 

 

./uapi/linux/sched.h

 

#define             SCHED_INTERACTIVE            7

#define            SCHED_UNEQUAL                        8

 

Each of these new scheduling policies have been implemented in one or more 
other UNIX operating systems in the past and currently to support a new 
scheduling behaviour. Isn’t ist about time that Linux supports these in the 
mainline OS.

 

SCHED_INTERACTIVE is meant to be used for tasks that are infrequently runnable, 
but once runnable should run with an absolute minimum latency. An example of 
this is the mouse icon. Currently this behaviour is determined based on past 
running behaviour where a minimum percentage of use of its runnable time has 
occurred and thus can loose its interactive as its runs. Common sense says that 
this type of process should always be interactive.

 

SCHED_UNEQUAL is meant to support an unfair scheduling policy for tasks that 
SHOULD run infrequently buy when runnable, SHOULD run to completion. This is 
more of a scalable flag, where the number of runnable tasks may increase, thus 
limiting its runnable time within a specific time window and/or the objects 
that the task is dealing with may increase that almost two times or more 
executing cycles are necessary for the task to run to completion. An example of 
this is a routing task that processes Link State Advertisements (LSAs) so a 
change in the routing table can be accomplished within a minimum of time. 
Without doing this network routing loops and black holes can exist for short 
periods of time loosing and/or increasing unnecessary control and data packet 
exchange.

 

Manual pages: Any manual page such as SCHED_SETATTR(2)  SHOULD be updated to 
acknowledge these new scheduling policies.

 

Applications: Tasks that display output about tasks / scheduling minimally need 
to be recompliled and be made aware of these new scheduling policies.

 

Inheritance: It is not believed that  these new policies SHOULD be inherited at 
time of a clone(2) / fork().

 

Weighting: Currently the suggested / proposed change is to implement a 
simplified differential weighting policy when SCHED_UNEQUAL is specified. A 
possible future change COULD support multiple UNEQUAL scheduling policies by 
combining an existing metric. This is for a later proposed change sometime 
after this proposed change is accepted.

 

Security / Denial Of Service (DoS) issues:

            SCHED_INTERACTIVE:  Code must be implemented to prevent repeatedly  
inserting SCHED_INTERACTIVE tasks onto cpu cores and to deny other tasks from 
executing.

 

            SCHED_UNEQUAL: Currently only when multiple tasks are runnable and 
consume the entire window of cpu cycles, by running this task two or three 
times in a row SHOULD on the worse case add less than 8% cpu cycles.

 

            To mitigate any scheduling disturbances setting these flags should 
be limited to an administrator aka root type user with specific capabilities.

 

TBDs: If Linux’s kernel.org sees that this feature is wanted in the near and/or 
distant future, then “UNKNOWNs / TBDs” or issues should be listed here.

 

This notice is not a proposal for kernel.org code integration at this time, but 
is intended for Copyright Notice and a general consensus whether this feature 
is beneficial for its future inclusion into Linux’s kernel.org.

 

Copyright Notice:

While this two page introduction on these new scheduling policies is being 
proposed, it is actually a minimal awareness document that should satisfy that 
a code change has been implemented within public domain source in the past and 
a determination whether this feature is wanted by kernel.org.

 

While the actual implementation code that uses these flags is proprietary, as 
most OS code is modified, it is coded / changed by multiple engineers and 
without general acceptance that this change is accepted, anything beyond an 
inception / concept proposal to specify new scheduling policy flags kernel.org 
is unnecessary at this time.

 

Warantee:

Usage etc, and incorporation of minimally tested / unknown / untested code is 
“AS-IS” with no warranties suggested or implied.

 

Reference for a past scheduler:

SunOS within the SVR4.x used SCHED_INTERACTIVE

 

VMware and others: Support a weighted process scheduler to allow UNEQUAL 
scheduling.

 

 

Mitchell Erblich
UNIX Kernel Engineer Developer


Mitchell Erblich
erbli...@earthlink.net



Reply via email to