Patent Application
20050015768
The present invention relates generally to the field of computer systems and, more particularly, to systems for scheduling process execution to provide optimal performance of the computer system.
The operation of modern computer systems is typically governed by an operating system (OS) software program which essentially acts as an interface between the system resources and hardware and the various applications which make requirements of these resources. Easily recognizable examples of such programs include Microsoft WindowsTM, UNIX, DOS, VxWorks, and Linux, although numerous additional operating systems have been developed for meeting the specific demands and requirements of various products and devices.
In general, operating systems perform the basic tasks which enable software applications to utilize hardware or software resources, such as managing I/O devices, keeping track of files and directories in system memory, and managing the resources which must be shared between the various applications running on the system. Operating systems also generally attempt to ensure that different applications running at the same time do not interfere with each other and that the system is secure from unauthorized use.
Depending upon the requirements of the system in which they are installed, operating systems can take several forms. For example, a multi-user operating system allows two or more users to run programs at the same time. A multiprocessing operating systems supports running a single application across multiple hardware processors (CPUs). A multitasking operating system enables more than one application to run concurrently on the operating system without interference. A multithreading operating system enables different parts of a single application to run concurrently. Real time operating systems (RTOS) execute tasks in a predictable, deterministic period of time. Most modern operating systems attempt to fulfill several of these roles simultaneously, with varying degrees of success.
Of particular interest to the present invention are operating systems which optimally schedule the execution of several tasks or threads concurrently and in substantially real-time. These operating systems generally include a thread scheduling application to handle this process. In general, the thread scheduler multiplexes each single CPU resource between many different software entities (the ‘threads’) each of which appears to its software to have exclusive access to its own CPU. One such method of scheduling thread or task execution is disclosed in U.S. Pat. No. 6,108,683 (the '683 patent). In the '683 patent, decisions on thread or task execution are made based upon a strict priority scheme for all of the various processes to be executed. By assigning such priorities, high priority tasks (such as video or voice applications) are guaranteed service before non critical or real-time applications. Unfortunately, such a strict priority system fails to address the processing needs of lesser priority tasks which may be running concurrently. Such a failure may result in the time-out or shut down of such processes which may be unacceptable to the operation of the system as a whole.
Another known system of scheduling task execution is disclosed in U.S. Pat. No. 5,528,513 (the '513 patent). In the '513 patent, decisions regarding task execution are initially made based upon the type of task requesting resources, with additional decisions being made in a round-robin fashion. If the task is an isochronous, or real-time task such as voice or video transmission, a priority is determined relative to other real-time tasks and any currently running general purpose tasks are preempted. If a new task is a general purpose or non-real-time task, resources are provided in a round robin fashion, with each task being serviced for a set period of time. Unfortunately, this method of scheduling task execution fails to fully address the issue of poor response latency in implementing hard real-time functions. Also, as noted above, extended resource allocation to real-time tasks may disadvantageously result in no resources being provided to lesser priority tasks.
Accordingly, there is a need in the art of computer systems for a system and method for scheduling the execution system processes which is both responsive to real-time requirements and also fair in its allocation of resources to non-real-time tasks.
The present invention overcomes the problems and disadvantages set forth above by providing a method, system and computer-readable medium for scheduling tasks, wherein a task switch request is initially received. A scheduling processor prioritizes the available tasks and inserts a highest priority task state into a first address register associated with a CPU. Next, the CPU suspends operation of the currently executing task and inserts a state of the suspended task into a second address register associated with the CPU. The CPU loads the task state from the first address register associated with the CPU and resumes the loaded task loaded. The scheduling processor then retrieves the task state from the second address register by the scheduling processor and schedules the retrieved task for subsequent execution.
The present invention can be understood more completely by reading the following Detailed Description of the Preferred Embodiments, in conjunction with the accompanying drawings.
The basic motivation for thread scheduling system of the present invention, is to reduce the overhead associated with context switching between tasks in an operating system. In a real-time operating system running many tasks (e.g., a network communications processor), the overheads of switching task contexts can consume a substantial proportion of the total CPU time. In general, a task is any single flow of execution and is analogous to an ATMOS process or a UNIX thread. Further, multiplexing of the CPU hardware between many tasks may be referred to as context switching. Such multiplexing can be accomplished in several ways, such as 1.) providing one dedicated CPU core per task, 2.) providing a hardware task switch on the CPU itself, and 3.) providing a software task switch.
It is assumed that the number of required tasks is greater than the number of possible CPU cores, so the first solution above can only be a partial solution. If it is assumed that the target CPU core is an ARM (or most other standard CPU cores), the second option is not available, since hardware tasks switches in these environments are not possible. Accordingly, for the assumes scenario, the solution must incorporate a software driven task switch.
Context switches may occur in response to pre-emptive time-slicing, wake requests (e.g.; by making a sleeping task runnable), or sleep requests from running task (e.g.; on read of an empty queue). For an ARM system, context switches can therefore occur as a result of interrupts (FIQ or IRQ), queue operations or software sleep requests. If queue operations are implemented in hardware, the ARM pre-fetch abort exception is a convenient way to force a task-suspend, while a dedicated FIQ or IRQ interrupt provides pre-emptive scheduling and task-wake functionality.
Accordingly, the general technique of the present invention is to remove as many of the processes as possible from the main system CPU to a separate scheduling processor, leaving only the operations that cannot easily be removed (assuming the main CPU is a standard processor which cannot be redesigned). In this manner, resources for the main CPU are maximized.
In one embodiment, processes which may be removed to the scheduling processor includes the following: the scheduling algorithm itself (i.e., deciding which task should run next, and deciding when to time-slice between tasks); the managing of task states, including each task's context information (which is largely represented by the contents of the CPU registers on most processors); and managing the information which controls task scheduling. In an operating system in which tasks communicate by using messages held on queues, a task is free to run unless it is suspended waiting for a message to arrive on an empty queue. The scheduler needs information relating to this suspension and queue arrival. Accordingly, the scheduling hardware also includes hardware to support the queue operations. Additionally, the scheduling hardware has all the task runnable/suspended information to hand, and can combine it with the conventional parameters such as task priorities, and timeslicing algorithms.
Through the implementation of designated scheduling hardware, the processes left to the main CPU are reduced to an absolute minimum. CPU processes may include the following: two fixed areas of memory reserved to hold 1.) the state of the current task, and 2.) the state of the next task chosen by the scheduler; suspension of the current task by dumping all registers into the “current task” memory area; and resuming the next task, by reloading all registers from the “next task” memory area.
Additionally, the main CPU is also provided with an interface for the scheduling hardware consisting of a number of hardware I/O registers mapped into its address space. The main processor uses these registers to initialize the scheduler, and to provide the arguments for queue operations, etc. Regarding the scheduling processor, it needs mechanisms to signal to the main CPU.
Referring now to
In addition to CPU 102, a discrete scheduling processor 104 is provided to assist with thread scheduling in the manner briefly disclosed above. A shared system memory 106 is further provided for maintaining the various queues and task states required by the present system. The CPU 102 includes a first input 108 for receiving a scheduler signal indicating that a pre-emptive task switch is required by issuing an interrupt to the CPU. Additionally, a second input 110 is provided for receiving a scheduler signal indicating that the current task must be suspended on a QueueGet operation. In one embodiment, task suspension is provided by raising a memory page-fault signal to the CPU 102 (in this manner, the operating system code in the CPU does not need any extra instructions to test whether a queue operation has worked—it simply initiates the queue operation via the hardware I/O registers, and if extra action is needed this will cause a page-fault exception which can invoke the appropriate routine).
CPU 102 further includes a first fixed memory area 111 for storing the state of the currently running task as well as a second fixed memory area 113 for storing the state of the next task. These memory areas are accessible to the scheduling processor 104 for enabling accurate scheduling of tasks.
Typically, conventional software schedulers incorporated into CPU's are limited by the finite size of the scheduler timeslice—often many milliseconds in modern systems. By providing hardware assist to the scheduling operation via the scheduling processor 104, the overhead of a thread context switch can be made dramatically smaller, either with a standard CPU core or with a modified core design. This allows much finer (microsecond level) timeslicing and hence improved real-time scheduling characteristics (which theoretically require an infinitesimal timeslice to provide idealized scheduler implementations). It should be understood that the hardware scheduling design may be rendered entirely in dedicated silicon, or in a software algorithm resident in a secondary CPU that offloads thread scheduling decisions from the CPU executing the threads.
Returning to
The queue manager 112 interacts with shared memory 106 (SRAM, or preferably SDRAM) to holds the queue control structures and items on the queues. The queue control structure maintains the list information, the queue type (e.g., LIFO (last in first out), FIFO (first in first out), etc.) and any references to task structures. Additionally, the queue manager 112 also interacts with the scheduling processor 104 to assert a task-demand on any put operation. For efficiency in implementation, this may be limited in one embodiment to the queue transition from empty to non-empty. The queue manager can assert a task-demand on any get operation that results in the requesting CPU being suspended. This is used to implement efficient task-locking primitives between control and data-path execution threads. The queue manager 112 also interacts with the CPU 102 requesting a queue operation. The queue manager can request an immediate task-switch if a get operation would have failed to return a queue entry.
The scheduling processor 104 is responsible for maintaining and calculating which task should be executing at any given moment. The most probable scheduling algorithm is likely to be a weighted-queue-dual-leaky-bucket priority encoder. However, the exact algorithm is flexible should remain programmable. As such, in a preferred embodiment, the scheduler 104 includes a programmable co-processor element, rather than a dedicated hardware block. The scheduling processor preferably maintains an adaptable listing of task states 122 for subsequent relay to memory area 113 associated with CPU 102.
In operation, an immediate task-switch request is implemented by raising a memory-page-fault to the target CPU 102. The scheduling processor 104 preferably maintains a target process for immediate switches (e.g., the next highest priority task, or the idle task from listing 122) which is placed into the memory area 113 associated with CPU 102. A conventional abort handler on the target CPU implements the context switch accordingly.
For pre-emptive task switches, the scheduling processor 104 continuously re-calculates task priorities and may select to request a pre-emptive task switch. In operation, the scheduling processor 104 sets the target-task state in the memory area 113, then issues an interrupt to the controlled CPU 102. This then handles the context switch in a conventional manner.
On targets which are general purpose processors (e.g. ARM), the processor itself must perform the task switch. The scheduling processor 104 assists this by providing registers 111 and 113 that specify where to save the existing state (111) and from where to load the new state (113). Task-switch requests are triggered by the memory-abort signal or by the interrupt line.
Additionally, the queue manager 112 may issue task-demand requests to the scheduling processor 104. There are several ways to accomplish this. By maintaining a FIFO of requests, a small FIFO queue of tokens is maintained between the queue manager 112 and scheduling processor 104 (e.g., for a hard-limit of 256 tasks, a short 256-byte FIFO could queue requests to run a task with the specified 8 bit task index). This methodology minimizes complexity between the queue manager 112 and scheduling processor 104 and allows for ‘stalls’ in processing requests. In an alternative embodiment, the queue manager 112 writes directly into the task-control-block (e.g., 122) associated with the respective queue. For example, there may be a byte or word sized field that is set zero on suspend, non-zero on demand.
Referring now to
Example ARM Software Context Switch
The following example assumes the following: a FIQ is generated to request a context switch; a fixed area in memory 111 receives the saved state of the interrupted task; and a fixed area in memory 113 contains the saved state of the task to be resumed. In this manner, the code for IRQ or abort handlers is analogous, requiring only one extra branch operation. This yields the following code for an ARM processor:
Queues associated with the present invention include packet queues and preferably have a number of properties including type (FIFO vs LIFO), depth, list head pointer, list tail pointer (FIFO only), task reference for demand-on-put, and task reference for demand-on-underflow. Further, entries on a queue contain the link pointer only (assume that this is the first word of memory in the object).
LIFO linked lists are desirable for use in implementing shared buffer pools since they are 1.) faster than FIFO queues and 2.) may have favorable interactions with some DRAM cache architectures. Further, packet oriented data-path tasks all have an associated input and output queue. These may reference either a free-pool or another processing task: the software queue APIs should not distinguish between the FIFO or LIFO modes.
Maintaining symmetry of operations between task queues and free-lists is important as it avoids the need for a given task to if the destination is in anyway ‘special’. Processing ‘chains’ built from tasks linked by message queues may only using packet-queue operations—i.e., you cannot mix and match packet queues and circular buffering. This will need to be explicitly set forth in the task scheduler.
Additionally, there is no hard binding between tasks and queues. That is, a task may choose to wait on any queue that does not already have an associated task waiting for it. Queues are transiently marked to indicate which task (if any) should be woken if a queue-put operation adds data to a queue or which should be woken if a queue-get operation causes a queue-underflow. Any queue operation that triggers a task-schedule event must clear the associated task from the queue structure to permit the input queue for a given task to be changed dynamically.
FIFO lists are used to build ordered queues of network data packets, or ordered queues of inter-application control messages. The number of items is not limited by the queue control structure. Knowledge is required of the structure of objects to be enqueued. LIFO lists are used to build resource pools, such as buffer pools. A LIFO buffer pool architecture has beneficial cache interactions on some hardware platforms, and generally provides faster access than FIFO queues. The number of items is not limited by the queue control structure. Knowledge is required of the structure of objects to be enqueued.
While the foregoing description includes many details and specificities, it is to be understood that these have been included for purposes of explanation only, and are not to be interpreted as limitations of the present invention. Many modifications to the embodiments described above can be made without departing from the spirit and scope of the invention.
The present application claims priority to co-pending U.S. Provisional Patent Application No. 60/437,043, filed Dec. 31, 2002, the entirety of which is incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 60437043 | Dec 2002 | US |
