The disclosed embodiments are generally directed to time-based scheduling of tasks in a computing system.
Many computing operations need to be performed periodically, such as keep-alive messages, reporting for health monitoring, and performing checkpoints. Other possibilities include periodically performing calculations that are used by cluster management software such as system load average, calculation of power metrics, and the like. In addition to fixed period processing, a process may want to schedule task execution at some random time in the future, such as for random time-based statistical sampling.
In order to provide a solution to this problem, periodic process execution, such as that provided by the cron and atd facilities in UNIX and LINUX, allow for time-based scheduling of processes. These solutions involve significant overhead in process creation, memory usage and the like and operate through the operating system (OS) for process creation and termination and are limited to standard central processing unit (CPU) processing. Therefore a need exists for a method and apparatus for time-based scheduling of tasks in a computer system directly by a task without the overhead of going through the OS for process creation and termination.
A computing device is disclosed. The computing device includes an Accelerated Processing Unit (APU) including at least a first Heterogeneous System Architecture (HSA) computing device and at least a second HSA computing device, the second computing device being a different type than the first computing device, and an HSA Memory Management Unit (HMMU) allowing the APU to communicate with at least one memory. The at least one computing task is enqueued on an HSA-managed queue that is set to run on the at least first HSA computing device or the at least second HSA computing device. The at least one computing task is enqueued using a time-based delay queue wherein the time-base uses a timer and is executed when the delay reaches zero. The at least one computing task is re-enqueued on the HSA-managed queue based on a repetition flag that triggers the number of times the at least one computing task is re-enqueued. The repetition field is decremented each time the at least one computing task is re-enqueued. The repetition field may include a special value (e.g., −1) to allow re-enqueuing of the at least one computing task indefinitely.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
The HSA platform provides mechanisms by which user-level code may directly enqueue tasks for execution on HSA-managed devices. These may include, but are not limited to, Throughput Compute Units (TCUs), Latency Compute Units (LCUs), DSPs, Fixed Function Accelerators, and the like. In its original embodiment, a user process is responsible for enqueuing tasks onto HSA managed tasks queues for immediate dispatch to HSA-managed devices. This extension to HSA provides a mechanism for tasks to be enqueued for execution at a designated future time. Also, this may enable periodic re-enqueuing such that a task may be issued once, but then be repeatedly re-enqueued on the appropriate task queue for execution at a designated interval. The present system and method provides a service to the UNIX/Linux cron services within the context of HSA. The present system and method provides a mechanism that allows scheduling and use of computational resources directly by a task without the overhead of going through the OS for process creation and termination. The present system and method may also extend the concepts of time-based scheduling to all HSA-managed devices and not just for standard CPU processing.
A computing device is disclosed. While any collection of processing units may be used, Heterogeneous System Architecture (HSA) devices may be used in the present system and method, and an exemplary computing device includes an Accelerated Processing Unit (APU) including at least one Central Processing Unit (CPU) having at least one core, and at least one Graphics Processing Unit (GPU) including at least one HSA compute unit (H-CU), and an HSA Memory Management Unit (HMMU or HSA MMU) allowing the APU to communicate with at least one memory. Other devices may include HSA devices, such as Processing-in-Memory (PIM), network devices, and the like. At least one computing task is enqueued on an HSA-managed queue that is set to run on the at least one CPU or the at least one GPU. The at least one computing task is enqueued using a time-based delay queue wherein the time-base uses a device timer and/or a universal timer and is executed when the delay queue reaches zero, such as when a DELAY VALUE is depleted, as described herein below. The at least one computing task is re-enqueued on the HSA-managed queue based on a repetition flag that triggers the number of times the at least one computing task is re-enqueued. The repetition field is decremented each time the at least one computing task is re-enqueued. The repetition field may include a special value to allow re-enqueuing of the at least one computing task indefinitely. The special value may be negative one.
The processor 102 may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, wherein each processor core may be a CPU or a GPU. The memory 104 may be located on the same die as the processor 102, or may be located separately from the processor 102. The memory 104 may include a volatile or non-volatile memory, for example, random access memory (RAM), dynamic RAM, or a cache.
The storage 106 may include a fixed or removable storage, for example, a hard disk drive, a solid state drive, an optical disk, or a flash drive. The input devices 108 may include a keyboard, a keypad, a touch screen, a touch pad, a detector, a microphone, an accelerometer, a gyroscope, a biometric scanner, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals). The output devices 110 may include a display, a speaker, a printer, a haptic feedback device, one or more lights, an antenna, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals).
The input driver 112 communicates with the processor 102 and the input devices 108, and permits the processor 102 to receive input from the input devices 108. The output driver 114 communicates with the processor 102 and the output devices 110, and permits the processor 102 to send output to the output devices 110. It is noted that the input driver 112 and the output driver 114 are optional components, and that the device 100 will operate in the same manner if the input driver 112 and the output driver 114 are not present.
In order to provide load balancing and/or to direct which CPU 340 or GPU 360 performs a given task (i.e. which queue 320 is populated with a task, runtime 310 may be used. This runtime 310 may provide load balancing across the CPUs to effectively manage the processing resource. However, because of the heterogeneous nature of the computer system 300, runtime 310 may have a more difficult task of load balancing because GPU 360 and CPU 340 may process through their respective queue 320 differently, such as in parallel vs. serial, for example, making it more difficult for runtime 310 to determine the amount of processing remaining for tasks in queue 320. As will be discussed herein below, a timer device (not shown in this configuration although it may be applied to computer system 300) may be used to provide load balancing and queue management according to an embodiment.
Additional hardware may also be utilized, including single instruction, multiple data (SIMD) 465. While several SIMDs 465 are shown, any number of SIMDs 465 may be used. SIMD 465 may include computers with multiple processing elements that perform the same operation on multiple data points simultaneously—there are simultaneous (parallel) computations, but only a single process (instruction) at a given moment. SIMD 465 may work on multiple tasks simultaneously, such as tasks where the entirety of the processing for GPU 460 is not needed. This may provide a better allocation of processing capabilities, for example. This is in contrast to CPUs 440 which generally operate on one single task at a time and then move to the next task. As will be discussed herein below, a timer device (not shown in this configuration although it may be applied to computer system 400) may be used to provide load balancing and queue management according to an embodiment.
As is illustrated in
As is illustrated in
Also illustrated in
As is illustrated in
As is illustrated in
HSA APU 710 may communicate with a system memory 750. System memory 750 may include one or both of coherent system memory 752 and non-coherent system memory 757.
HSA 700 may provide a unified view of fundamental computing elements. HSA 700 allows a programmer to write applications that seamlessly integrate CPUs 720, also referred to as latency compute units, with GPUs 730, also referred to as throughput compute units, while benefiting from the best attributes of each.
GPUs 730 have transitioned in recent years from pure graphics accelerators to more general purpose parallel processors, supported by standard APIs and tools such as OpenCL and DirectCompute. Those APIs are a promising start, but many hurdles remain for the creation of an environment that allows the GPU 730 to be used as fluidly as the CPU 720 for common programming tasks including different memory spaces between CPU 720 and GPU 730, non-virtualized hardware, and so on. HSA 700 removes those hurdles, and allows the programmer to take advantage of the parallel processor in the GPU 730 as a peer to the traditional multi-threaded CPU 720. A peer device may be defined as an HSA device that shares the same memory coherency domain as another device.
HSA devices 700 communicate with one another using queues. Queues are an integral part of the HSA architecture. Latency processors 720 already send compute requests to each other in queues in popular task queuing run times like ConcRT and Threading Building Blocks. With HSA, latency processors 720 and throughput processors 730 may queue tasks to each other and to themselves. The HSA runtime performs all queue creation and destruction operations. A queue is a physical memory area where a producer places a request for a consumer. Depending on the complexity of the HSA hardware, queues might be managed by any combination of software or hardware. Hardware managed queues have a significant performance advantage in the sense that an application running on latency processors 720 can queue work to throughput processors 730 directly, without the need for any intervening operating system calls. This allows for very low latency communication between devices. With this, the throughput processors 730 device may be viewed as a peer device. Latency processors 720 may also have queues. This allows any device to queue work for any other device.
Specifically, as shown in
The current HSA task queuing model provides for enqueuing of a task on an HSA-managed queue for immediate execution. This enhancement allows for two additional capabilities (1) a delayed enqueuing and/or execution of a task and, (2) periodic re-insertion of the task upon a task queue.
For delayed enqueuing and/or execution of a task, the HSA device 700 may utilize a timer capability that may be set to cause an examination of a time-based schedule/delay queue after a given interval. Referring now to
The timer implementation may be limited to a larger time granularity than specified in the work item. In that case, the implementation may choose the rules for deciding how to schedule the task. For example, the implementation may round to the nearest time unit, or may decide to round to the next highest or next lowest time unit.
The work item information may also contain information to indicate whether or not the task is to be re-enqueued and, if so, how many times to be re-enqueued and the re-enqueue schedule policy: This may enable the periodic re-insertion of the task upon a task queue. The work item may contain a RE-ENQUEUE FLAG. If the FLAG is non-zero, then once the work item has completed execution, the FLAG may be re-scheduled based on the values of a REPETITION FIELD, a DELAY VALUE, and the re-enqueue schedule policy based on the value of a periodic FLAG.
Referring now to
The time interval with which the task is re-enqueued is based on the value of a PERIODIC FLAG. If the FLAG is non-zero, then the task is re-enqueued for the interval in the DELAY FIELD. One optional extension is to allow for re-enqueuing with a random interval. This may support a random time-based execution. This may be useful for random-based sampling of data streams, system activity, monitored values, and the like. In order to accomplish this random-based sampling, if the PERIODIC FLAG is zero, then the interval is random rather than periodic and the re-enqueue interval is randomly chosen in the range from 0 and the value of the DELAY FIELD. In other words, the value of the DELAY FIELD is the upper bound of the delay range.
Additional facilities may be provided for such capabilities as retrieving information about scheduled tasks and canceling currently scheduled tasks. The HSA task queuing protocol may be enhanced to support these commands. Some embodiments may maintain uniqueness among tasks via task identifiers, system name and work item counter, or the like. The result of the cancel command is to remove the specified periodic task from the timer queue so that it will no longer be scheduled for execution. The present system may also return a list and status of tasks currently in the delay queue. Status can include such information as: time to next execution, re-enqueue flag value, re-enqueue count value, and interval value.
The cancel and list/status operations may also provide for privileged (e.g., root) access. This may allow system administrators as well as processes executing with sufficient privilege to query and possibly cancel time-based tasks.
The present system and method may be configured such that there is a single HSA scheduler device that is used to schedule periodic tasks on any available HSA devices in a node, rather than a scheduler integrated with each HSA device. In either the single HSA scheduler device per node, or an integrated HSA scheduler per HSA device, the interaction from the client of the task queue may be the same. That is, the HSA implementation may have a single HSA scheduler device to manage the scheduling or may have an HSA scheduler per HSA device.
It should be understood that many variations are possible based on the disclosure herein. Although features and elements are described above in particular combinations, each feature or element may be used alone without the other features and elements or in various combinations with or without other features and elements.
The methods provided may be implemented in a general purpose computer, a processor, or a processor core. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine. Such processors may be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediary data including netlists (such instructions capable of being stored on a computer readable media). The results of such processing may be maskworks that are then used in a semiconductor manufacturing process to manufacture a processor which implements aspects of the embodiments.
The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a non-transitory computer-readable storage medium for execution by a general purpose computer or a processor. Examples of non-transitory computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).