US20110010716A1

Movatterモバイル変換

Info

Publication number: US20110010716A1
Application number: US12/815,299
Authority: US
Inventors: Arvind Raghuraman; Daniel Driscoll; Michael Trippi
Original assignee: Mentor Graphics Corp
Current assignee: Mentor Graphics Corp
Priority date: 2009-06-12
Filing date: 2010-06-14
Publication date: 2011-01-13
Also published as: US10228970B2; US20130318531A1; US20160217006A1

Abstract

Methods and apparatuses for developing symmetric and asymmetric software applications on a single monolithic symmetric multiprocessing operating system are disclosed. An enabling framework for one or all of the following software design patterns; application work load sharing between all processors present in a multi-processor system in a symmetric fashion, application work load sharing between all processors present in a multi-processor system in a asymmetric fashion using task to processor soft affinity declarations, application work load sharing between all processors present in a multi-processor system using bound computational domains may be provided. Further, a particular computational task or a set of computational tasks may be bound to a particular processing unit. Subsequently, when one such task is to be scheduled, the symmetric multiprocessing operating system ensures that the bound processing unit processes the instruction. When the bound processing unit is not processing the particular computational instruction, the bound processing unit may enter a low power or idle state.

Description

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 61/186,760, entitled “Domain Bounding for Symmetric Multiprocessing Systems,” filed on Jun. 12, 2009, and naming Arvind Raghuraman et al. as inventors, which application is incorporated entirely herein by reference.

FIELD OF THE INVENTION

The invention relates to the field of computing on multi-processor computer architectures. More particularly, various implementations of the invention are applicable to developing application software with symmetric and/or asymmetric software designs on symmetric multi-processor embedded systems.

BACKGROUND OF THE INVENTION

An embedded system may be described as a special purpose computing system designed to perform one or a few dedicated functions. Embedded systems are commonly used in consumer devices like personal digital assistants, mobile phones, videogame consoles, microwaves, washing machines, alarm systems, and digital cameras. In addition to the consumer space, embedded systems are used in nearly every industry, from telecommunications to manufacturing, and from transportation to medical devices. In fact, embedded systems are so commonly in use today that it is not feasible to exhaustively list specific examples.

The term “embedded system” does not have a precise definition, and determining what is and is not an embedded system can be difficult. For example, a general purpose computer, such as a laptop, is not typically characterized as an embedded system. However, a laptop is usually composed of a multitude of subsystems such as the hard disk drive, the motherboard, the optical drive, the video processing unit, and various communication devices. Many of the individual subsystems comprising the laptop may themselves be embedded systems.

The complexity of embedded systems can vary from, for example, systems with a single microcontroller chip and a light emitting diode to systems with multiple microprocessor units and various peripheral communication interfaces and mechanical parts. Manufacturers of modern microprocessors are increasingly adding components and peripheral modules to their microprocessors, creating what may be thought of as embedded processors. This type of embedded system is often referred to as a system on a chip (SoC). A simple example of a system on chip is an application-specific integrated circuit (ASIC) packaged with a universal serial bus (USB) port. Additionally, embedded systems range from those having no user interface at all to those with full user interfaces similar to a desktop operating system.

There are many advantages to using embedded systems. For example, an embedded system typically is designed to do some specific task, as opposed to being a general purpose computer with a wide range of features for performing many different tasks. As a result, design engineers can optimize the embedded system for the desired task, which assists in reducing the size and cost of the device as well as increasing its reliability and performance.

Symmetric Multiprocessing

As stated above, embedded systems may often contain more than one processing unit. Embedded systems having more than one processing unit are often referred to as a multi-processor system. As will be apparent from the discussion below, various implementations of the present invention are particularly applicable to multi-processor systems having more than one homogeneous processor, that is, they have multiple identical processing units. In general, a multi-processor computer system is any computing configuration that utilizes more than one processing unit. The processing units will typically share a memory. Additionally, one operating system is often used to control the entire system. In this type of arrangement, multiple computational tasks, or “instructions,” may be processed at the same time, such as, for example, one by each processing unit. This type of computing arrangement (i.e. where multiple processing units share a memory and are controlled by a single instance of an operating system) is often referred to as “symmetric multiprocessing” or SMP.

As indicated, an operating system is used to control the symmetric multiprocessing system. Controlling which processing units execute which tasks and when, is managed by the operating system, which typically operates on one of the processing units in the system. This operating system is often referred to as an SMP operating system or a symmetric multiprocessing operating system. As those of skill in the art can appreciate, various symmetric multiprocessing operating systems currently exist. For example, OS X, Linux, and various UNIX based operating systems are all capable of operating in a symmetric multiprocessing environment. Typically, a symmetric multiprocessing operating system allows any processor to work on any task, no matter the type of task or where the data for that task is located. Additionally, many symmetric multiprocessing operating systems move tasks between processors to balance the workload efficiently. One reason for this is to keep all processing units in the system busy. Often, application software developed on such systems is referred to as having a symmetric software design. Additionally, some symmetric multiprocessing operating systems provide a user with the capability to define “task” to processing unit affinity, such as, for example, with an “affinity definition.” In such systems, tasks affined with affinity definitions always execute on the processing unit it was affined to when the task is scheduled. Application software developed on symmetric multi-processing systems using this task to processor affinity feature are often referred to as having an asymmetric software design.

This type of task balancing and workload sharing may however, in some cases, be disadvantageous. This is particularly true in an embedded system where hardware and power constraints may dictate that particular processing units be employed to perform a particular type of task during particular times or operate on data located in a specific location.

SUMMARY OF THE INVENTION

Various implementations of the present invention provide methods and apparatuses for developing symmetric and asymmetric software applications on a single monolithic symmetric multiprocessing operating system. Various implementations of the invention may provides an enabling framework for one or all of the following software design patterns; application work load sharing between all processors present in a multi-processor system in a symmetric fashion, application work load sharing between all processors present in a multi-processor system in a asymmetric fashion using task to processor soft affinity declarations, application work load sharing between all processors present in a multi-processor system using bound computational domains.

With some implementations, a particular computational task is “linked” or a set of computational tasks may be bound to a particular processing unit. Subsequently, when one such task is to be scheduled, the symmetric multiprocessing operating system ensures that the bound processing unit processes the instruction. When the bound processing unit is not processing the particular computational instruction, the bound processing unit may enter a low power or idle state.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described by way of illustrative embodiments shown in the accompanying drawings in which like references denote similar elements, and in which:

FIG. 1 shows an illustrative computing environment;

FIG. 2 shows a portion of the illustrative computing environment ofFIG. 1 in greater detail;

FIG. 3 illustrates a conventional symmetric multiprocessing system;

FIG. 4 illustrates a method of bounding the processing domain of a symmetric multiprocessing system;

FIG. 5 illustrates a symmetric multiprocessing system according to various implementations of the present invention;

FIG. 6 illustrates the symmetric multiprocessing system ofFIG. 5 in alternate detail; and

FIG. 7 illustrates the symmetric multiprocessing system ofFIG. 5 in alternate detail.

DETAILED DESCRIPTION OF ILLUSTRATIVE IMPLEMENTATIONS

The operations of the disclosed implementations may be described herein in a particular sequential order. However, it should be understood that this manner of description encompasses rearrangements, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, for the sake of simplicity, the illustrated flow charts and block diagrams typically do not show the various ways in which particular methods can be used in conjunction with other methods.

It should also be noted that the detailed description sometimes uses terms like “determine” to describe the disclosed methods. Such terms are often high-level abstractions of the actual operations that are performed. The actual operations that correspond to these terms will often vary depending on the particular implementation, and will be readily discernible by one of ordinary skill in the art.

The methods described herein can be implemented by software stored on a computer readable storage medium and executed on a computer. Furthermore, the selected methods could be executed on a single computer or a computer networked with another computer or computers. For clarity, only those aspects of the software germane to these disclosed methods are described; product details well known in the art are omitted.

Illustrative Computing Environment

As the techniques of the present invention may be implemented using software instructions executed by one or more programmable computing devices, the components and operation of a generic programmable computer system on which various implementations of the invention may be employed will first be described. Further, because of the complexity of some electronic design automation processes and the large size of many circuit designs, various electronic design automation tools are configured to operate on a computing system capable of simultaneously running multiple processing threads. The components and operation of a computer network having a host or master computer and one or more remote or slave computers therefore will be described with reference toFIG. 1. This operating environment is only one example of a suitable operating environment, however, and is not intended to suggest any limitation as to the scope of use or functionality of the invention.

InFIG. 1, thecomputer network101 includes amaster computer103. In the illustrated example, themaster computer103 is a multi-processor computer that includes a plurality of input andoutput devices105 and amemory107. The input andoutput devices105 may include any device for receiving input data from or providing output data to a user. The input devices may include, for example, a keyboard, microphone, scanner or pointing device for receiving input from a user. The output devices may then include a display monitor, speaker, printer or tactile feedback device. These devices and their connections are well known in the art, and thus will not be discussed at length here.

Thememory107 may similarly be implemented using any combination of computer readable media that can be accessed by themaster computer103. The computer readable media may include, for example, microcircuit memory devices such as read-write memory (RAM), read-only memory (ROM), electronically erasable and programmable read-only memory (EEPROM) or flash memory microcircuit devices, CD-ROM disks, digital video disks (DVD), or other optical storage devices. The computer readable media may also include magnetic cassettes, magnetic tapes, magnetic disks or other magnetic storage devices, punched media, holographic storage devices, or any other medium that can be used to store desired information.

As will be discussed in detail below, themaster computer103 runs a software application for performing one or more operations according to various examples of the invention. Accordingly, thememory107 stores software instructions109A that, when executed, will implement a software application for performing one or more operations. Thememory107 also storesdata109B to be used with the software application. In the illustrated embodiment, thedata109B contains process data that the software application uses to perform the operations, at least some of which may be parallel.

Themaster computer103 also includes a plurality ofprocessor units111 and aninterface device113. Theprocessor units111 may be any type of processor device that can be programmed to execute the software instructions109A, but will conventionally be a microprocessor device. For example, one or more of theprocessor units111 may be a commercially generic programmable microprocessor, such as Intel® Pentium® or Xeon™ microprocessors, Advanced Micro Devices Athlon™ microprocessors, ARM©, or Motorola 68K.Coldfire microprocessors. Alternately or additionally, one or more of theprocessor units111 may be a custom-manufactured processor, such as a microprocessor designed to optimally perform specific types of mathematical operations. Theinterface device113, theprocessor units111, thememory107 and the input/output devices105 are connected together by abus115.

With some implementations of the invention, themaster computing device103 may employ one ormore processing units111 having more than one processor core. Accordingly,FIG. 2 illustrates an example of amulti-core processor unit111 that may be employed with various embodiments of the invention. As seen in this figure, theprocessor unit111 includes a plurality ofprocessor cores201. Eachprocessor core201 includes acomputing engine203 and amemory cache205. As known to those of ordinary skill in the art, a computing engine contains logic devices for performing various computing functions, such as fetching software instructions and then performing the actions specified in the fetched instructions. These actions may include, for example, adding, subtracting, multiplying, and comparing numbers, performing logical operations such as AND, OR, NOR and XOR, and retrieving data. Eachcomputing engine203 may then use itscorresponding memory cache205 to quickly store and retrieve data and/or instructions for execution.

Eachprocessor core201 is connected to aninterconnect207. The particular construction of theinterconnect207 may vary depending upon the architecture of theprocessor unit201. With someprocessor cores201, such as the Cell microprocessor created by Sony Corporation, Toshiba Corporation and IBM Corporation, theinterconnect207 may be implemented as an interconnect bus. Withother processor units201, however, such as the Opteron™ and Athlon™ dual-core processors available from Advanced Micro Devices of Sunnyvale, Calif., theinterconnect207 may be implemented as a system request interface device. In any case, theprocessor cores201 communicate through theinterconnect207 with an input/output interfaces209 and a memory controller211. The input/output interface209 provides a communication interface between theprocessor unit201 and thebus115. Similarly, the memory controller211 controls the exchange of information between theprocessor unit201 and thesystem memory107. With some implementations of the invention, theprocessor units201 may include additional components, such as a high-level cache memory accessible shared by theprocessor cores201. More particularly, with various implementations, theprocessor cores201 all have access to the same memory cache, which may, for example, be thememory cache units205 shown. This is often referred to as “cache coherency.”

WhileFIG. 2 shows one illustration of aprocessor unit201 that may be employed by some embodiments of the invention, it should be appreciated that this illustration is representative only, and is not intended to be limiting. For example, some embodiments of the invention may employ amaster computer103 with one or more Cell processors. The Cell processor employs multiple input/output interfaces209 and multiple memory controllers211. Also, the Cell processor has ninedifferent processor cores201 of different types. More particularly, it has six or more synergistic processor elements (SPEs) and a power processor element (PPE). Each synergistic processor element has a vector-type computing engine203 with 128×128 bit registers, four single-precision floating point computational units, four integer computational units, and a 256 KB local store memory that stores both instructions and data. The power processor element then controls that tasks performed by the synergistic processor elements. Because of its configuration, the Cell processor can perform some mathematical operations, such as the calculation of fast Fourier transforms (FFTs), at substantially higher speeds than many conventional processors.

It also should be appreciated that, with some implementations, amulti-core processor unit111 can be used in lieu of multiple,separate processor units111. For example, rather than employing sixseparate processor units111, an alternate implementation of the invention may employ asingle processor unit111 having six cores, two multi-core processor units each having three cores, amulti-core processor unit111 with four cores together with two separate single-core processor units111, etc.

Returning now toFIG. 1, theinterface device113 allows themaster computer103 to communicate with the

slave computers

117A,117B,117C . . .117xthrough a communication interface. The communication interface may be any suitable type of interface including, for example, a conventional wired network connection or an optically transmissive wired network connection. The communication interface may also be a wireless connection, such as a wireless optical connection, a radio frequency connection, an infrared connection, or even an acoustic connection. Theinterface device113 translates data and control signals from themaster computer103 and each of the slave computers117 into network messages according to one or more communication protocols, such as the transmission control protocol (TCP), the user datagram protocol (UDP), and the Internet protocol (IP). These and other conventional communication protocols are well known in the art, and thus will not be discussed here in more detail.

Each slave computer117 may include amemory119, aprocessor unit121, an interface device122, and, optionally, one more input/output devices125 connected together by a system bus127. As with themaster computer103, the optional input/output devices125 for the slave computers117 may include any conventional input or output devices, such as keyboards, pointing devices, microphones, display monitors, speakers, and printers. Similarly, theprocessor units121 may be any type of conventional or custom-manufactured programmable processor device. For example, one or more of theprocessor units121 may be commercially generic programmable microprocessors, such as Intel® Pentium® or Xeon™ microprocessors, Advanced Micro Devices Athlon™ microprocessors or Motorola 68K/Coldfire® microprocessors. Alternately, one or more of theprocessor units121 may be custom-manufactured processors, such as microprocessors designed to optimally perform specific types of mathematical operations. Still further, one or more of theprocessor units121 may have more than one core, as described with reference toFIG. 2 above. For example, with some implementations of the invention, one or more of theprocessor units121 may be a Cell processor. Thememory119 then may be implemented using any combination of the computer readable media discussed above. Like theinterface device113, theinterface devices123 allow the slave computers117 to communicate with themaster computer103 over the communication interface.

In the illustrated example, themaster computer103 is a multi-processor unit computer withmultiple processor units111, while each slave computer117 has asingle processor unit121. It should be noted, however, that alternate implementations of the invention may employ a master computer havingsingle processor unit111. Further, one or more of the slave computers117 may havemultiple processor units121, depending upon their intended use, as previously discussed. Also, while only a

single interface device

113 or123 is illustrated for both themaster computer103 and the slave computers, it should be noted that, with alternate embodiments of the invention, either thecomputer103, one or more of the slave computers117, or some combination of both may use two or more

different interface devices

113 or123 for communicating over multiple communication interfaces.

Furthermore, it is to be appreciated, that although in the example, themaster computer103 and the slave computers117 are shows as individual discrete units, some implementations may package themaster computers103 and the slave computers117 into a single unit, such as, for example, a System-on-Chip device.

With various examples of the invention, themaster computer103 may be connected to one or more external data storage devices. These external data storage devices may be implemented using any combination of computer readable media that can be accessed by themaster computer103. The computer readable media may include, for example, microcircuit memory devices such as read-write memory (RAM), read-only memory (ROM), electronically erasable and programmable read-only memory (EEPROM) or flash memory microcircuit devices, CD-ROM disks, digital video disks (DVD), or other optical storage devices. The computer readable media may also include magnetic cassettes, magnetic tapes, magnetic disks or other magnetic storage devices, punched media, holographic storage devices, or any other medium that can be used to store desired information. According to some implementations of the invention, one or more of the slave computers117 may alternately or additions be connected to one or more external data storage devices. Typically, these external data storage devices will include data storage devices that also are connected to themaster computer103, but they also may be different from any data storage devices accessible by themaster computer103.

It also should be appreciated that the description of the computer network illustrated inFIG. 1 andFIG. 2 is provided as an example only, and it not intended to suggest any limitation as to the scope of use or functionality of alternate embodiments of the invention.

Symmetric Multiprocessing Systems

As indicated above, a conventional symmetric multiprocessing system includes a plurality of processing units, capable of independently executing various tasks. For example,FIG. 3 illustrates a conventionalsymmetric multiprocessing system301. As can be seen from this figure, thesystem301 includes acomputing environment303, includingprocessing units305. In various implementations of the invention, thecomputing environment303 may be formed by thecomputer network101 ofFIG. 1. As such, theprocessing units305 would comprise the

processor units

111 and121 shown in the figure. With some implementations, thecomputing environment303 may be formed by themaster computer103. Accordingly, theprocessing units305 would comprise theprocessor units111. As can be appreciated, various components of thecomputing environment303 are not shown in this example. For example, thecomputing environment303 would likely include a memory component, which is some cases, may be implemented by thememory107 shown inFIG. 1.

Thesystem301 also includes asymmetric multiprocessing scheduler307 having asymmetric multiprocessing queue309. Furthermore, as can be seen, thesymmetric multiprocessing queue309 includestasks311. As detailed above, in a conventional symmetric multiprocessing system, any of thetasks311 may be executed on any of theprocessing units305. Thesymmetric multiprocessing scheduler307 may assignparticular tasks311 to any of theprocessing units305, and may change or move the assignments dynamically to balance the computational load efficiently.

However, as indicated above, this has some disadvantageous. One such disadvantage is that processingunits305 are increasingly more specific toparticular tasks311. This is often the case in embedded systems, where a particular processing unit may have been designed for a specific function, such as, for example, video encoding. Additionally, ones of theprocessing units305 may have much higher power consumption needs than other ones of theprocessing units305. As such, use of these processingunits305 could be better controlled to manage power consumption for thesystem301.

Domain Bounding for Symmetric Multiprocessing Systems

As used herein, aprocessing unit305 may be either a microprocessor or a core within a multi-core microprocessor, such as, for example, theprocessor unit111 and theprocessor core201 respectively. Furthermore, applicants would like to point out that although in practice, a distinction between a symmetric computing architecture (i.e. homogenous processing units that share memory) and an asymmetric computing architecture (i.e. heterogeneous processing units that share memory) may be made; herein, when referencing a symmetric multiprocessing system, not all processing units must be homogenous. For example, as used herein, a symmetric multiprocessing system may have a combination of single core microprocessors and multi-core microprocessors. Furthermore, the microprocessors may have different hardware specifications. Still, further, the microprocessors may have different computer processor architectures.

FIG. 4 illustrates amethod401 for bounding the processing domain of a symmetric multiprocessing system. For example, themethod401 may be implemented in conjunction with the examplesymmetric multiprocessing system501 shown inFIG. 5. As can be seen from these figures, thesymmetric multiprocessing system501 includes, among other items, acomputing environment503 having processing units505. In various implementations, thesymmetric multiprocessing system501 may be formed by modifying thesymmetric multiprocessing system301 shown inFIG. 3. Still, in some implementations, thesymmetric multiprocessing system501 may be formed by utilizing thecomputing network101, or alternatively, from themaster computer103 as thecomputing environment503.

Returning toFIG. 4, themethod401 includes anoperation403 for initializing the processing units505 within thesymmetric multiprocessing system501 and an operation405 for booting a symmetricmultiprocessing operating system507 on one or more of theprocessing units503. As shown in this Figure, the symmetricmultiprocessing operating system507 is booted onto theprocessing unit505i. The processing unit505 that loads the operating system (e.g. theprocessing unit505iin this example) is often referred to as the “boot processor.” In various implementations of the invention, the boot processor is used exclusively by the symmetricmultiprocessing operating system507 for operations related to managing thesymmetric multiprocessing system501. In alternative implementations, the boot processor is used to load the operating system, but is not used exclusively for operations related to managing thesymmetric multiprocessing system501. Accordingly, in some implementations, the boot processor is available for general computing tasks unrelated to operating system management. With some implementations of the invention, theoperation403 initializes all the processing units505. With alternative implementations, theoperation403 initializes only the boot processor.

Themethod401 further includes an operation407 for loading thescheduler509. As can be seen fromFIG. 5, thescheduler509 includes asymmetric multiprocessing queue511. As can be further seen from this figure, thesystem501 additionally includes a user application515 having tasks517. As used herein, the tasks517 may be explicit instructions that processing units505 may directly execute. Alternatively, the tasks517 may be higher level operations that the symmetricmultiprocessing operating system507 will translate into instructions that the processor units505 may execute.

AlthoughFIG. 5 illustrates a single user application515, and one set of tasks517, in various implementations, more than one user application515 may be executed by the symmetricmultiprocessing operating system507. Additionally, in some implementations, the user application515 may have multiple sets of tasks517. Further still, as can be appreciated by those of skill in the art, the set of tasks517 is typically not static. More particularly, the set of tasks517 changes as the user application is executed.

Themethod401 additionally includes an operation409 for generating a boundcomputational domain queue513 and an operation411 for moving selected tasks517 to the boundcomputational domain queue513. In various implementations of the invention, as a user application515 is loaded by the symmetricmultiprocessing operating system509 and tasks517 associated with the user application515 are identified, all the tasks517 may be initially loaded into thesymmetric multiprocessing queue511. More particularly, when thescheduler509 is first loaded by the operation407, the scheduler may only include thesymmetric multiprocessing queue511, which will include all of the tasks517.

In various implementations of the invention, the operation409 and the operation411 are performed as a result of a software application interface (API), which is some cases, may be the result of a users input. With some implementations, the operation409 and the operation411 are triggered without user input, such as, for example, based upon the type of user application515 or the type of task517. In various implementations of the invention, the operations409 and411 may be repeated a number of times, resulting in more than one boundcomputational domain queue513 being created within thescheduler509.

Themethod401 further includes an operation413 for forming a processing domain boundary for the boundcomputational domain queue513. As stated above, in various implementations, an “affinity” is created between a boundcomputational domain queue513 and one or more processing units505. Alternatively, a “link” is created between a boundcomputational domain queue513 and one or more processing units505. These example processing domain boundaries are discussed in greater detail below.

Bound Computational Domain with Affinity

In various implementations, the operation413 “affines” one or more of the processing units505 to the boundcomputational domain queue513. Tasks517 included in a boundcomputational domain queue513 that is “affined” to a particular processing unit505 are said to be affined to that particular processing unit505. Tasks517 that are affined to a particular processing unit505 are given “priority” by thescheduler509 to execute on that particular processing unit505. However, when tasks517 having an affinity for the selected processing unit505 are not being executed, the processing unit505 is available for scheduling non-affined tasks517 by thescheduler509. Priority of execution may be shown by thescheduler509 by transferring execution of non-affined tasks517 to idle processing units505 when affined tasks517 need to be executed. Alternatively, priority may be shown by stalling execution of the affined task517 until the affined processing unit505 is available for executing tasks517.

In some implementations, a single processing unit505 is affined to a boundcomputational domain queue513 by the operations413. With some implementations, multiple processing units505 are affined to a boundcomputational domain queue513. For example,FIG. 6 illustrates thesymmetric multiprocessing system501 ofFIG. 5, where the boundcomputational domain queue513 has been affined to the processing unit505iiiand theprocessing unit505n, as illustrated by theboundary603. As can be seen from this figure, the user application515 is not shown. However, the tasks517 from the user application515 have been moved into thesymmetric multiprocessing queue511 and the boundcomputational domain queue513.

As a result of the affinity created by the operation415 (as illustrated by the boundary603) thescheduler509 may assign the tasks517iv,517v, and517nto execute on either of the processing unit505iiior505n. Additionally, thescheduler509 may assign thetasks517i,517ii, or517iiito execute on the processing unit505ii. Alternatively, if the processing unit505iiiis not executing tasks517 from the boundcomputational domain queue513, tasks517 from thesymmetric multiprocessing queue511 may be executed on the processing unit505iii. Alternatively still, if theprocessing unit505nis not executing tasks517 from the boundcomputational domain queue513, tasks517 from thesymmetric multiprocessing queue511 may be executed on theprocessing unit505n.

Bound Computational Domain with Link

As stated above, with some implementations, the operation413 may “link” one or more the processing units505 to a boundcomputational domain queue513. Processing units505 that have been linked to a particular task517 or set of tasks517 can only execute those tasks517. When there are no linked tasks to execute, the processor remains idle, as opposed to becoming available for scheduling as in the case of an affined processing unit505.

FIG. 7 illustrates thesymmetric multiprocessing system501 shown inFIG. 5 andFIG. 6. However,FIG. 7 includes aboundary703 that shows a link, as opposed to an affinity as shown by theboundary603 inFIG. 6. As can be seen fromFIG. 7,boundary603 isolates the processing units505iiior505nto the boundcomputational domain513. As a result, only the tasks517iv,517v, and517nmay be executed by the processing units505iiiand505n.

In various implementations, as opposed to bounding a queue of tasks517, such as, for example, the boundedcomputational domain queue513, as described above, the processing domain for individual tasks517 may be bound. For example, the operation415 may directly affine thetask517vwith the processing unit505iii. As opposed to including thetask517vinto a boundcomputational domain queue513 and then bounding the processing domain for thequeue513.

As stated above, in various implementations of the invention, a boundcomputational domain queue513 may be created as a result of some user input. This may be facilitated by providing an application programming interface (API) instruction set that includes instructions for defining and manipulating boundcomputational domain queues513. The following is an illustrative set of application programming interface instructions that may be provided in various implementations of the invention.

CONCLUSION

Although certain devices and methods have been described above in terms of the illustrative embodiments, the person of ordinary skill in the art will recognize that other embodiments, examples, substitutions, modification and alterations are possible.

It is intended that the following claims cover such other embodiments, examples, substitutions, modifications and alterations within the spirit and scope of the claims.

Claims

1. A computer-implemented method for bounding the processing domain in a symmetric multiprocessing system, the method comprising:

identifying a symmetric multiprocessing system, the symmetric multiprocessing system including a plurality of processing units;

identifying a plurality of tasks to be scheduled for execution by the symmetric multiprocessing system;

forming a computationally bound task queue;

moving selected ones of the plurality of tasks to be scheduled to the computationally bound task queue; and

bounding the processing domain for the computationally bound task queue.

2. The computer-implemented method recited inclaim 1, further comprising:

causing a symmetric multiprocessing operating system to boot onto a one of the plurality of processing units.

3. The computer-implemented method recited inclaim 2, further comprising:

loading a symmetric multiprocessing operating system scheduler.

4. The computer-implemented method recited inclaim 3, the method act for identifying a plurality of tasks to be scheduled for execution by the symmetric multiprocessing operating system comprising:

identifying a symmetric multiprocessing task queue within the symmetric multiprocessing operating system scheduler;

identifying a plurality of tasks within the symmetric multiprocessing task queue; and

designating the identified tasks as the plurality of tasks to be scheduled.

5. The computer-implemented method recited inclaim 4, the method act of forming a computationally bound task queue comprising:

receiving an instruction from a user of the symmetric multiprocessing system to create a bound computational domain; and

forming a task queue within the symmetric multiprocessing operating system scheduler to represent the computationally bound task queue.

6. The computer-implemented method recited inclaim 5, the instruction including a listing of one or more of the plurality of tasks to be scheduled and the method act of moving selected ones of the plurality of tasks to be scheduled to the computationally bound task queue comprising:

adding the one or more of the plurality of tasks to be scheduled listed in the instruction to the computationally bound task queue; and

removing the one or more of the plurality of tasks to be scheduled listed in the instruction from the symmetric multiprocessing task queue.

7. The computer-implemented method recited inclaim 6, the instruction including a listing of one or more of the plurality processing units and the method act of bounding the processing domain for the computationally bound task queue comprising affining the computationally bound task queue to the one or more of the plurality of processing units listed in the instruction.

8. The computer-implemented method recited inclaim 6, the instruction including a listing of one or more of the plurality processing units and the method act of bounding the processing domain for the computationally bound task queue comprising linking the computationally bound task queue to the one or more of the plurality of processing units listed in the instruction.

9. The computer-implemented method recited inclaim 1, further comprising

forming a second computationally bound task queue;

moving selected ones of the plurality of tasks to the second computationally bound task queue; and

bounding the processing domain for the computationally bound task queue.

10. The computer-implemented method recited inclaim 1, further comprising:

unbounding the computationally bound task queue; and

removing the computationally bound task queue from the symmetric multiprocessing system.

11. One or more tangible computer-readable media, having computer executable instructions for bounding the processing domain in a symmetric multiprocessing system stored thereon, the computer executable instructions comprising:

causing a computer to perform a set of operations; and

wherein the set of operations include:

forming a computationally bound task queue;

bounding the processing domain for the computationally bound task queue.

12. The one or more tangible computer-readable media recited inclaim 11, the symmetric multiprocessing system including a symmetric multiprocessing operating system scheduler and the operation for identifying a plurality of tasks to be scheduled for execution by the symmetric multiprocessing operating system comprising:

identifying a symmetric multiprocessing task queue;

designating the identified tasks as the plurality of tasks to be scheduled.

13. The one or more tangible computer-readable media recited inclaim 12, the operation for forming a computationally bound task queue comprising:

14. The one or more tangible computer-readable media recited inclaim 13, the instruction including a listing of one or more of the plurality of tasks to be scheduled and the operation for moving selected ones of the plurality of tasks to be scheduled to the computationally bound task queue comprising:

15. The one or more tangible computer-readable media recited inclaim 14, the instruction including a listing of one or more of the plurality processing units and the operation for bounding the processing domain for the computationally bound task queue comprising affining the computationally bound task queue to the one or more of the plurality of processing units listed in the instruction.

16. The one or more tangible computer-readable media recited inclaim 14, the instruction including a listing of one or more of the plurality processing units and the operation for bounding the processing domain for the computationally bound task queue comprising linking the computationally bound task queue to the one or more of the plurality of processing units listed in the instruction.

17. A symmetric multiprocessing system adapted to allowing bounded processing, the system comprising:

a plurality of processing units;

a plurality of tasks to be scheduled for execution by the system; and

a memory including a set of instructions that cause the system to perform:

forming a computationally bound task queue;

bounding the processing do

main for the computationally bound task queue.

18. The symmetric multiprocessing system recited inclaim 17, wherein the set of instructions are included in an application programming interface.

19. The symmetric multiprocessing system recited inclaim 18, the instruction for bounding the processing domain for a computationally bound task queue comprising:

receiving a listing of one or more of the plurality processing units

receiving a boundary relationship affining the computationally bound task queue to the one or more of the plurality of processing units listed in the instruction.

20. The symmetric multiprocessing system recited inclaim 18, the instruction for bounding the processing domain for a computationally bound task queue comprising:

receiving a listing of one or more of the plurality processing units

receiving a boundary relationship linking the computationally bound task queue to the one or more of the plurality of processing units listed in the instruction.