Not Applicable.
Not Applicable.
Not Applicable.
The invention disclosed broadly relates to the field of power and workload management for computers and more particularly relates to the field of timer interrupt management.
Non-real-time operating systems rely on a periodic timer interrupt. A periodic timer interrupt is used by the operating system to keep track of process times, facilitate multitasking, determine if software timers has expired, and keep track of time. The repetition time interval of the timer interrupt is configured at OS startup time by writing an appropriate value into the load register of a hardware timer. In turn, the timer loads this value into a countdown register which decrements at a well known speed. When the counter reaches zero, the timer generates an interrupt. The timer then automatically reloads the initial load value into the countdown register and the count down process starts all over again. The net effect is that the timer has been setup to generate periodic timer interrupts.
On every timer interrupt, the timer interrupt service routine (ISR) is executed. The ISR updates time variables such as OS time and process times, as well as checks status of queues and lists and correspondingly run content or mark content for execution. One particularly interesting context is when the operating system (OS) is idling, i.e., when there is no computational work to be done. This happens when there are no processes actively running, no tasks on the queues and no expired software timers. The idle context is interesting in that in an OS like LINUX, and other non-real-time OSs, the only useful thing, if any, that happens in a “workless” timer interrupt is the updating of the OS time. It can be demonstrated that the servicing of the timer interrupt can be postponed until there is real work to be done while still maintaining OS time. This is accomplished by incorporating a so-called work dependent timing (WDT) scheme into the OS. The WDT scheme skips workless timer interrupts by parsing the software timer list, retrieving the timeout value of that software timer that has the nearest timeout value, reprogramming the hardware timer with the nearest timeout value and reading time from a real-time clock on every hardware interrupt.
Skipping “workless” timer interrupts has several power benefits. Firstly, it is wasteful to service workless timer interrupts. Secondly, it can be demonstrated that by skipping timer interrupts it may be possible to transition into a more efficient low power state while the OS is idling. Lastly, it can be shown that in certain classes of small form-factor mobile devices, the skipping of the timer interrupts results in significant energy savings from the elimination of transition energies associated with exploiting certain highly efficient low power states.
Another interesting scenario where skipping timer interrupts is important is in systems that run multiple images of the OSs. In such systems the accumulated impact from workless timer interrupts has a significant impact on the processor workload as well as consume unnecessary energy. Obviously when skipping workless timer interrupts, this workload is significantly reduced.
Even though power and workload is reduced by skipping workless timer interrupts, excess power is still consumed and excess workload still exists due to work related timer interrupts. Some of this excess power and workload is a direct outcome of the uncoordinated manner with which the work related timer interrupts occur.
Therefore, a need exists to overcome the problems with the prior art as discussed above, and particularly for a way to manage multiple software timers for optimum efficiency.
Briefly, according to an embodiment of the present invention, a method for pooling software timers is disclosed. The method includes storing information associated with at least one software timer, wherein the information includes phase adjustment data and a timeout value for the at least one software timer and reading the information that was stored. The method further includes performing at least one of phase aligning the at least one software timer using the phase adjustment data and modifying the timeout value of at least one software timer, such that more than one software timer expires at the same time.
Also disclosed is an information processing system for pooling timers. The information processing system includes a memory for storing information associated with at least one timer, wherein the information includes at least one of phase adjustment data and a timeout value for the at least one timer. The processor is further configured for reading the information that was stored and performing at least one of phase aligning the at least one timer using the phase adjustment data and modifying the timeout value of at least one timer, such that more than one timer expires at the same time.
The method can also be implemented as machine executable instructions executed by a programmable information processing system or as hard coded logic in a specialized computing apparatus such as an application-specific integrated circuit (ASIC). Thus, also disclosed is a computer readable medium including computer instructions for pooling timers. The computer readable medium includes instructions for storing information associated with at least one timer, wherein the information includes at least one of phase adjustment data and a timeout value for the at least one timer and reading the information that was stored. The computer readable medium further includes instructions for performing at least one of phase aligning the at least one timer using the phase adjustment data and modifying the timeout value of at least one timer, such that more than one timer expires at the same time
The foregoing and other features and advantages of the present invention will be apparent from the following more particular description of the preferred embodiments of the invention, as illustrated in the accompanying drawings.
The subject matter, which is regarded as the invention, is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other features and also the advantages of the invention will be apparent from the following detailed description taken in conjunction with the accompanying drawings. Additionally, the left-most digit of a reference number identifies the drawing in which the reference number first appears.
The present invention overcomes the problems with the prior art as discussed above by reducing the number of work related interrupts. The present invention is beneficial as it allows for reductions in power consumption and in computational load in a real-time operating system (OS) and in an OS that skips workless timer interrupts.
The present invention allows an OS to manipulate the timeout value of software timers. The OS can phase align software timers and change the timeout values of software timers for the purpose of pooling, or grouping, them together. This results in a further reduction in the number of work related timer interrupts, since pooling the software timers encourages expiration of multiple software timers in a single timer interrupt.
In an embodiment of the present invention, an OS implementing the present invention utilizes a WDT timing scheme which skips workless timer interrupts as outlined above. The OS ensures that a hardware timer will be programmed to wake up the OS in due time to call an expired software timers callback function. The hardware timer is programmed with the smallest timeout value amongst all the timers in the software timer list.
The present invention effectuates software timer pooling in order to reduce power consumption and workload of an information processing system. Below is a brief description of timer pooling as performed by one embodiment of the present invention. In the following, a “timer pop” is used to refer to the expiration of one or more software timers at a particular moment. The term “phase shifting” is used to refer to the act of displacing, or shifting, the times that a periodic timer pop occurs. The term “phase aligning” is used to refer to the act of phase shifting one or more periodic timers for the purpose of promoting that at least one timer pop coincides with the timer pop of another software timer. Phase shifting may be a one time adjustment to the phase, or it may be spread out over several timer pops. Phase shifting should not impact the long term periodicity of a periodic timer.
As described above, the TMR1 is phase aligned with TMR2 such that both timers expire at the same time, thus resulting in TMR1′. Generally, phase alignment of two timers results in simultaneous timer pops at least every (period1×period2) seconds, wherein period1 is the period of the first timer and period2 is the period of the second timer. Thus, comparing TMR1′ with TMR2, the graph 100 shows simultaneous timer pops at 20 seconds and 40 seconds.
Next, it is determined by the OS that the period of TMR1 can be adjusted to within +/−1 second, allowing for the period of TMR1 to be adjusted to 4 seconds. This results in TMR1″, which is identical to TMR2. Thus, comparing TMR1″ with TMR2, the graph 100 shows simultaneous timer pops at 4 seconds, 8 seconds, 12 second, etc.
In the following, the term “timeout value” is defined as the time at which a software timer must expire and the associated timer callback function must be executed.
From a software flow perspective, a software timer works as follows. The calling module 302 in the application 206 defines a timer callback function, callback_fct( ). The calling module 302, such as a device driver module or a user application, may sign up for a callback by making a call to add_timer(timer) which is exported by the API 204. add_timer( ), which is a function of the OS 202, adds a pointer to timer to a timer list and where timer is a software data structure which has at least two members: callback_fct, which contains the address of callback_fct( ), and expires, which contains the associated timer expiration time, or timeout value. The callback function is called by the OS 202 after the timeout interval of the timer.
Below is an example of a C++ style definition of a timer data structure, timer_pool, suitable for timer pooling. timer_pool is used for communicating timer parameters to the OS 202 and is suitable for inserting a timer into a double linked list. Note that “OS” and “CM” indicates whether it is the OS 202 or the calling module 302, respectively, which controls the data structure member, i.e., which is permitted to change it.
Referring to the C++ style definition above, the data structure members prev and next are pointers to the previous and next timers in the linked list. The data structure members callback_fct and data are the usual callback address and callback data of a timer function. The last nine members enables the OS 202 and pooling algorithm 306 to pool timers.
The data structure member period is the long term average periodicity of the timer. If the calling module 302 supplies a value of zero in this member, the OS 202 ignores it and treats the timer as a one-shot timer. If a non-zero value is supplied, the OS 202 interprets this in two ways. Firstly, the OS 202 assumes responsibility for maintaining the timer. Secondly, the OS 202 must ensure that the supplied value for the periodicity is obeyed. The purpose of this member and the implementation of the function for maintaining the timer are described in greater detail below. The calling module 302 can take over control at any time by deleting the timer and adding a new timer in which period has a value of zero. The OS 202 always updates the expires_os member to enable the calling module to keep an eye on the timer.
The data structure members expires_min and expires_max represent the minimum and maximum values of the timeout value. They are initially supplied by the calling module 302. The OS 202 may update these values for OS-maintained periodic timers. The data structure members phase_min and phase_max represent the minimum and maximum values of a phase shift, or phase adjustment, that may be used by the OS 202 in an accumulated fashion. Together, these four values are used by the OS 202 to calculate the bounds of the actual timeout value which is eventually programmed into the hardware timer. The data structure members phase_min and phase_max allow the OS 202 to insert a timer, in a more coarse fashion, into the rhythm of all the other timers. For an OS-maintained periodic timer (i.e., period>0), these members may only be used once. The manner in which these data structure members are utilized is described in greater detail below.
The data structure member expires_pref is the preferred value of the timeout value. It is only used for one-shot timers and is ignored for non-zero values in period. A value outside the range between expires_min and expires_max is ignored. Only the calling module can modify this data member.
The data structure member expires_os_min is a lower boundary value for the actual timeout value. This member is calculated by the OS 202 as expires_os_min=expires_min+phase_min. The data structure member expires_os is the running timeout value initially calculated by the OS 202 as expires_os=expires_max+phase_max but which may later change, e.g., at the time of programming the hardware timer. The purpose of this data structure member is to enable the calling module 302 to keep track of the actual timeout values for guaranteeing a certain long-term averaged periodicity. For example, this may be required by multimedia applications that can tolerate momentary variations in the callback time. expires_os is not trustworthy until its timer expires, as explained more fully below. For an OS-maintained timer, all three members are updated every time the timer expires. The manner in which these data structure members are utilized is described in greater detail below.
The timer pooling algorithm 306 takes into consideration all existing timers and uses the associated values passed in the data structure 308. It is assumed that timers are added to the double linked timer list described above and that timers are inserted in order of increasing value of expires_os which contains the maximum allowable timeout value as described above. The timer that has the nearest, i.e., shortest, timeout value in the list is denoted as timer0.
The hardware timer is only reprogrammed in two instances: when the OS 202 enters the WDT timing mode (i.e., when there is no work to be done) and when the OS 202 enters the conventional periodic timing (PT) mode which is entered when there is work to be done. It is when entering the WDT mode that the timer pooling algorithm is applied. When entering the PT mode, the hardware timer is programmed to generate periodic timer interrupts. PT mode is always entered whenever a hardware interrupt is detected by the OS. When it is time to reprogram the hardware timer in the WDT mode, the OS first evaluates and modifies the timer list as shown in the C++ code below which defines a timer pooling function 306, timer_pooling( ), suitable for pooling timers together. Briefly, timer_pooling( ) first determines if a timer can be pooled together with the head timer, timer0, then calculates its new timeout value and then repositions the pool timer within the timer list. All timers in the timer list are examined. Typically timer_pooling( ) would be called upon entering the WDT mode.
The basic approach to pooling timers, as exemplified above, is to stretch the timeout value of the nearest timer(s) as much as possible on every reprogramming of the hardware timer in WDT mode. The nearest timer, timer0, is always at its maximum timeout value and is used as the reference point for adjusting other potential pool timers in the timer list which generally have longer timeout values, though they may also have the same timeout value as timer0. An adjusted pool timer is never moved to the head position, but rather is inserted after timer0. Note that timer0 is always assumed to have the maximum timeout value in the expires_os. As may be seen from the C++ code above, the pool timers that are grouped with timer0 do not necessarily have the maximum possible timeout value in the expires_os. The adjusted timers merely have the same value in expires_os as timer0 does. The only instances where timer0 must be replaced is 1) if it is deleted, 2) if it is moved, or 3) if a new timer is added which has a smaller timeout value.
Currently, in certain operating systems such as LINUX, a timer is deleted from the linked list when it expires. Second, if the deleted timer is a periodic timer, the calling module that owns the timer will subsequently add a new timer. The purpose of the period member in the pool_timer structure above is to eliminate these two steps. Instead, on expiration of the timer, the OS 202 adds the value of period to the timeout boundary values, expires_min and expires_max, recalculates expires_os, as described earlier, and then moves the timer to the proper position in the linked list according to the value of expires_os. The various timeout values of an expired OS-maintained period timer may be updated as shown in the C++ code below which defines a function, add_timer( ), suitable for determining timeout boundary values in timers, including OS-maintained periodic timers.
After updating the data members of a new timer or after updating the timeout value of a periodic timer, the timer must be either added to the timer list or repositioned in the timer list, respectively, which is done in insert_timer( ). insert_timer( ) can easily determine if timer is a new or existing timer by examining the the *prev and *next pointers which will only point to the null address if the timer is new. Inserting timers into a linked list is well known to anyone skilled in the art of systems programming.
An extension to the data structure 308 includes a data structure member representing limits on the timer's jitter in the case of an OS-maintained periodic timer. Another extension to the data structure 308 includes a data structure member representing the time duration over which the periodicity specified in period must be maintained. In the embodiments above, the periodicity is only guaranteed to be within the timeout limits represented by expires_min and expires_max.
The present invention can be realized in hardware, software, or a combination of hardware and software. A system according to a preferred embodiment of the present invention can be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system—or other apparatus adapted for carrying out the methods described herein—is suited. A typical combination of hardware and software could be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
An embodiment of the present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods. Computer program means or computer program in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or, notation; and b) reproduction in a different material form.
A computer system may include, inter alia, one or more computers and at least a computer readable medium, allowing a computer system, to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium may include non-volatile memory, such as ROM, Flash memory, Hard disk drive memory, CD-ROM, and other permanent storage. Additionally, a computer readable medium may include, for example, volatile storage such as RAM, buffers, cache memory, and network circuits. Furthermore, the computer readable medium may comprise computer readable information in a transitory state medium such as a network link and/or a network interface, including a wired network or a wireless network, that allow a computer system to read such computer readable information.
The computer system can include a display interface 508 that forwards graphics, text, and other data from the communication infrastructure 502 (or from a frame buffer not shown) for display on the display unit 510. The computer system also includes a main memory 506, preferably random access memory (RAM), and may also include a secondary memory 512. The secondary memory 512 may include, for example, a hard disk drive 514 and/or a removable storage drive 516, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 516 reads from and/or writes to a removable storage unit 518 in a manner well known to those having ordinary skill in the art. Removable storage unit 518, represents a floppy disk, a compact disc, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 516. As will be appreciated, the removable storage unit 518 includes a computer readable medium having stored therein computer software and/or data.
In alternative embodiments, the secondary memory 512 may include other similar means for allowing computer programs or other instructions to be loaded into the computer system. Such means may include, for example, a removable storage unit 522 and an interface 520. Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 522 and interfaces 520 which allow software and data to be transferred from the removable storage unit 522 to the computer system.
The computer system may also include a communications interface 524. Communications interface 524 allows software and data to be transferred between the computer system and external devices. Examples of communications interface 524 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface 524 are in the form of signals which may be, for example, electronic, electromagnetic, optical, or other signals capable of being received by communications interface 524. These signals are provided to communications interface 524 via a communications path (i.e., channel) 526. This channel 526 carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, and/or other communications channels.
In this document, the terms “computer program medium,” “computer usable medium,” and “computer readable medium” are used to generally refer to media such as main memory 506 and secondary memory 512, removable storage drive 516, a hard disk installed in hard disk drive 514, and signals. These computer program products are means for providing software to the computer system. The computer readable medium allows the computer system to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium, for example, may include non-volatile memory, such as a floppy disk, ROM, flash memory, disk drive memory, a CD-ROM and other permanent storage. It is useful, for example, for transporting information, such as data and computer instructions, between computer systems. Furthermore, the computer readable medium may comprise computer readable information in a transitory state medium such as a network link and/or a network interface, including a wired network or a wireless network, that allow a computer to read such computer readable information.
Computer programs (also called computer control logic) are stored in main memory 506 and/or secondary memory 512. Computer programs may also be received via communications interface 524. Such computer programs, when executed, enable the computer system to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 504 to perform the features of the computer system. Accordingly, such computer programs represent controllers of the computer system.
Although specific embodiments of the invention have been disclosed, those having ordinary skill in the art will understand that changes can be made to the specific embodiments without departing from the spirit and scope of the invention. The scope of the invention is not to be restricted, therefore, to the specific embodiments. Furthermore, it is intended that the appended claims cover any and all such applications, modifications, and embodiments within the scope of the present invention.