Message-Id: <9989192B-F7F2-4B0E-BD96-21E0862BBD0F@earthlink.net>
Date:   Thu, 11 Jul 2019 16:51:17 -0700
From:   Mitchell Erblich <erblichs@...thlink.net>
To:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Propose New Linux Scheduling Policies



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
erblichs@...thlink.net

Powered by blists - more mailing lists