Intel Chief Evangelist Comments on Linux Scheduler

ByeByeWintel writes "James Reinders is Intel's Chief Evangelist for Intel's Software Development Products. In a recent interview on Devx.com he stated: 'If I could get ONE wish fulfilled would be for OS scheduling to focus on processes, and not threads, for scheduling. And demand that processes manage their scheduling of threads ... There is a lot of opportunity for operating systems to offer these types of control in the 'running of applications' interfaces. I'd like an OS to let me specify the 'world' my application runs in (which processors, how many, etc.) These interfaces are available in Windows at run time (the task manager will let you adjust where a running task can go).'"

Comments

Re:So do it

[Anonymous Coward]

Way ahead of you.

$ sudo apt-get install schedutils
...
Unpacking schedutils (from .../schedutils_1.5.0-1_amd64.deb) ...
Setting up schedutils (1.5.0-1) ...

$ man taskset | cat
Reformatting taskset(1), please wait...
TASKSET(1) Linux User's Manual TASKSET(1)

NAME
taskset - retrieve or set a processes's CPU affinity

SYNOPSIS
taskset [options] [mask | list ] [pid | command [arg]...]

DESCRIPTION
taskset is used to set or retrieve the CPU affinity of a running pro-
cess given its PID or to launch a new COMMAND with a given CPU affin-
ity. CPU affinity is a scheduler property that "bonds" a process to a
given set of CPUs on the system. The Linux scheduler will honor the
given CPU affinity and the process will not run on any other CPUs.
Note that the Linux scheduler also supports natural CPU affinity: the
scheduler attempts to keep processes on the same CPU as long as practi-
cal for performance reasons. Therefore, forcing a specific CPU affin-
ity is useful only in certain applications.

The CPU affinity is represented as a bitmask, with the lowest order bit
corresponding to the first logical CPU and the highest order bit corre-
sponding to the last logical CPU. Not all CPUs may exist on a given
system but a mask may specify more CPUs than are present. A retrieved
mask will reflect only the bits that correspond to CPUs physically on
the system. If an invalid mask is given (i.e., one that corresponds to
no valid CPUs on the current system) an error is returned. The masks
are typically given in hexadecimal. For example,

0x00000001
is processor #0

0x00000003
is processors #0 and #1

0xFFFFFFFF
is all processors (#0 through #31)

When taskset returns, it is guaranteed that the given program has been
scheduled to a legal CPU.

OPTIONS
-p, --pid
operate on an existing PID and not launch a new task

-c, --cpu-list
specifiy a numerical list of processors instead of a bitmask.
The list may contain multiple items, separated by comma, and
ranges. For example, 0,5,7,9-11.

-h, --help
display usage information and exit

-V, --version
output version information and exit

USAGE
The default behavior is to run a new command with a given affinity
mask:
taskset [mask] -- [command] [arguments]

You can also retrieve the CPU affinity of an existing task:
taskset -p [pid]

Or set it:
taskset -p [mask] [pid]

PERMISSIONS

its called "scheduler activations"

[paulbd]

what is being discussed is called "scheduler activations" within the CS community (or was). its an old idea. i did some work on a real-world (hah) implemention back in the early 1990's when i worked at UWashington. google it. Solaris actually added this design at least 10 years ago (plus or minus 2 years). its a very cool OS design, but can also be hard to get the implementation right; it also requires both kernel and userspace implementations.

the basic idea is that the kernel doesn't try to decide which threads within a task/process should run. as long as the process is scheduled to have access to a CPU, whenever its about to block (e.g. on disk i/o) or to be granted a processor from another task, the kernel tells the user space scheduler what is going on. scheduling is then done in user space, where maximal knowledge about the applications internal design and thread priorities can be easily accessed.

there are several papers on this design, ranging from Tom Anderson's "original" through reports on various implementation efforts. it was certainly fun trying to write a user space context switch routine that has to be reentrant itself, not to mention trying to deal with priority inversion issues. i think sun simply worked around the latter problem with some design assumptions/limitations, but i don't know for sure.