Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Preferential Affinity for Process Scheduling

IP.com Disclosure Number: IPCOM000115005D
Original Publication Date: 1995-Feb-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 76K

Publishing Venue

IBM

Related People

Karp, AH: AUTHOR [+2]

Abstract

When multiprogramming on a multiprocessor system, a process can be scheduled to run on the next available processor. It is often desirable to have a given process run on the same processor that it last ran on. Conventional schemes either force a process always to use the same processor or to be run on any available processor. In some situations, it is better to set a preference.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Preferential Affinity for Process Scheduling

      When multiprogramming on a multiprocessor system, a process can
be scheduled to run on the next available processor.  It is often
desirable to have a given process run on the same processor that it
last ran on.  Conventional schemes either force a process always to
use the same processor or to be run on any available processor.  In
some situations, it is better to set a preference.

      Multiprocessor systems are most commonly used for
multiprogramming in which a number of processes share the processors.
Processes are taken off processors for a variety of reasons - I/O
requests, page faults, interrupts, expired time slices, etc.  When
the descheduled process is ready to run, it is put on the run queue.
The operating system takes processes from the run queue and schedules
them onto processors.  In general, the process at the head of the run
queue will be run on the next available processor.

      There are times when it is desirable to run a process on the
processor it last used.  For example, if the processor used vector
registers, their contents may be intact when the processor gets to
the front of the queue.  Also, if the processor has a large cache
memory, some or all of the process's data may still be in the cache.

      The conventional approach is to assign a processor affinity to
the task.  Once the processor affinity is set, that process will only
run on the specified processor.  If the process reaches the front of
the queue, the operating system will skip it unless the requested
processor is available.  Unfortunately, the process may end up
waiting longer than it should; it might complete faster if it were
eventually scheduled onto another processor.  An extreme example is
when the required processor has failed.  In this case any process
waiting for that processor will never complete.

      It might be worth waiting a little while for the desired
processor before taking the next available one.  For example, the
time saved by not reloading the...