Slashdot Mirror


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).'"

5 of 178 comments (clear)

  1. I don't understand by Junta · · Score: 4, Informative

    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).'" Isn't this *exactly* what numactl gives you (hint, you don't have to run numa for numactly to allow processes to be bound to specific sets of processors).
    --
    XML is like violence. If it doesn't solve the problem, use more.
  2. Re:So do it by Anonymous Coward · · Score: 5, Informative
    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

  3. Re:Puh-leeeeze! by jcr · · Score: 4, Informative

    First of all, any job with the word 'evangelist' directly implies 'highly paid fanboy.'

    I worked with the Evangelists in Apple Developer Relations, and my direct personal experience tells me that you're full of shit.

    Apple's Technology Evangelists are some of the most talented technical marketing professionals I've ever met, and now that I'm an outside developer, they do a great job for me pulling the levers and turning the gears that I need to get my products out the door, connecting our company with customer prospects, and finding and introducing us to other companies that we can collaborate with. I'd hire any of those guys in a heartbeat for either a development or a marketing position, if I could get them out of Apple.

    -jcr

    --
    The only title of honor that a tyrant can grant is "Enemy of the State."
  4. Available through POSIX pthread and RT extension by EMB+Numbers · · Score: 4, Informative

    I think that what Intel's Evangelist wants is already available through standard POSIX pthreads and the POSIX-RT extensions.

    man pset_create, pset_assign, or pset_bind.

    I just checked and it seems that Solaris, HP-UX support this POSIX feature. Maybe it's only Linux that is non-standard: I found ythis quote: http://developers.sun.com/solaris/articles/solaris_linux_app.html

    "Both Linux and the Solaris OS support the notion of binding a process or thread to a processor. Linux allows binding to a set of processors for non-exclusive use of those processors. The Solaris OS allows binding to a set of processors for exclusive use, (that is, CPU fencing), but does not allow binding to a group for non-exclusive use (except via Solaris Zones?). Linux does not have a mechanism for CPU fencing, though implementations can be found on the web (see, for example, the CPUSETS for Linux page on the bullopensource.org site). The Linux system calls that are processor affinity based are sched_setaffinity(2) and sched_getaffinity(2)."

  5. its called "scheduler activations" by paulbd · · Score: 5, Informative

    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.