Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk12062016; d=earthlink.net;
  b=rwqx+vyeKMurkH0OFvHbLfVaybiiM6r5v2L+hmvnBERJ+rDNnAn6JWiCshFpUh+cFUrZzaOPfjUx9XAYsPh8LsW0999WmaGrgszzODBoAwFLv2RvfUsSV2r2yJ8S3xAFOFpeqY6d183BneVh+csZV/GWjf688tFNavw4vIwi0Guwbx1orVgPhat1HEacH6c5SF9phrx3wGnwfViTkvffAiF/z7QuZGeeT+GoZfMOoBjjeCcV7za5Vt4/3druSLpjxhWCoWBNL8l8BgOUvZTg8Jf0jXw+pi6IFkxpdVDLkPd/3ngCZfH0ltwIKVGZ+nFa7QXjKMNowPcL/Adf/xTgNg==;
  h=Received:From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id:Date:To:Mime-Version:X-Mailer:X-ELNK-Trace:X-Originating-IP;
From:   Mitchell Erblich <erblichs@earthlink.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Propose New Linux Scheduling Policies
Message-Id: <9989192B-F7F2-4B0E-BD96-21E0862BBD0F@earthlink.net>
Date:   Thu, 11 Jul 2019 16:51:17 -0700
To:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Proposed new Linux Scheduling Policies                                   =
 July 2019

Version 0.9

=20

=20

./uapi/linux/sched.h

=20

#define             SCHED_INTERACTIVE            7

#define            SCHED_UNEQUAL                        8

=20

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=E2=80=99t ist about time that Linux =
supports these in the mainline OS.

=20

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.

=20

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.

=20

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

=20

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

=20

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

=20

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.

=20

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.

=20

            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.

=20

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

=20

TBDs: If Linux=E2=80=99s kernel.org sees that this feature is wanted in =
the near and/or distant future, then =E2=80=9CUNKNOWNs / TBDs=E2=80=9D =
or issues should be listed here.

=20

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=E2=80=99s kernel.org.

=20

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.

=20

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.

=20

Warantee:

Usage etc, and incorporation of minimally tested / unknown / untested =
code is =E2=80=9CAS-IS=E2=80=9D with no warranties suggested or implied.

=20

Reference for a past scheduler:

SunOS within the SVR4.x used SCHED_INTERACTIVE

=20

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

=20

=20

Mitchell Erblich
UNIX Kernel Engineer Developer


Mitchell Erblich
erblichs@earthlink.net