Coordinating device and application break events for platform power saving

Systems and methods of managing break events may provide for detecting a first break event from a first event source and detecting a second break event from a second event source. In one example, the event sources can include devices coupled to a platform as well as active applications on the platform. Issuance of the first and second break events to the platform can be coordinated based on at least in part runtime information associated with the platform.

BACKGROUND

1. Technical Field

Embodiments generally relate to the management of platform break events. More particularly, embodiments relate to coordinating the issuance of break events from different sources in order to enhance platform power savings.

In conventional mobile computing platforms, multiple IO (input/output) devices (e.g., communication interfaces) and software applications may tend to generate uncoordinated break events, which can prevent the platform and its components from rapidly entering lower power states and staying in those states for extended periods of time. Indeed, shorter and sub-optimal battery life could result in the platform remaining in high power states more often than necessary.

DETAILED DESCRIPTION

Embodiments may provide for a method in which a first break event from a first event source is detected and a second break event from a second event source is detected. The method can also provide for coordinating issuance of the first and second break events to a platform based on at least in part runtime information associated with the platform.

Other embodiments may include a computer readable storage medium having a set of instructions which, if executed by a processor, cause a computer to detect a first break event from a first event source and detect a second break event from a second event source. The instructions can also cause a computer to coordinate issuance of the first and second break events to a platform based on at least in part runtime information associated with the platform.

In addition, embodiments can include an apparatus having an input/output (IO) module with logic to detect a first break event from a first event source and detect a second break event from a second event source. The logic may also coordinate issuance of the first and second break events to a platform based on at least in part runtime information associated with the platform.

Embodiments may also include a system having a first event source, a second event source, a processor and an input/output (IO) module coupled to the processor. The IO module can have logic to detect a first break event from the first event source, and detect a second break event from a second event source. In addition, the logic may coordinate issuance of the first and second break events to the system based on at least in part runtime information associated with the system.

Turning now toFIG. 1, a plurality of break events10(10a-10f) from different sources (e.g., power management entities) is shown before and after coordinating issuance of the break events10to a platform. In the illustrated example, an input/output (IO) event10a(e.g., interrupt) from a device such as a mouse is requested for time instance t1, and a timer event10bfrom an active application running on the platform is requested for time instance t2. In addition, a series of IO events10cfrom another device such as a network interface card (NIC) may be requested for time instance t3. As will be discussed in greater detail, the IO events10cmight themselves be grouped together by a coalescing unit disposed either on the NIC or at a central location. An IO event10dfrom an audio device may also be requested for time instance t4. Additionally, the illustrated example demonstrates the detection of timer events10eand10ffrom active applications for time instances t5and t6, respectively. In their native state, the break events10might have a time profile that would prevent the platform from entering certain power saving states for extended periods of time.

Accordingly, the issuance of the break events10to the platform can be coordinated to enable the platform to reduce power consumption. For example, the illustrated IO event10afrom the mouse is deferred until a deferred time instance t1dso that it may be aligned with the issuance of the application timer event10b, which may be issued at a deferred time instance t2d. In another example, the timer event10bmight be a non-deferrable event. In such a case, the IO event10amay be deferred, whereas the timer event10bcould be issued as scheduled. In either case, an extended idle time period12can be created, wherein the platform may enter deeper power saving states (e.g., ACPI/Advanced Configuration and Power Interface Specification, ACPI Specification, Rev. 4.0, Jun. 16, 2009, low power states) more quickly and for longer periods of time due to the extended time period12. In addition, the IO events10cfrom the NIC can be aligned with the IO event10dfrom the audio device at deferred time instances t3dand t4d, respectively, to create another extended time period14. Similarly, the application timer events10eand10fmay be deferred to time instances t5dand t6d, respectively, which can result in an extended time period16. Simply put, the extended time periods12,14,16may enable enhanced platform power savings and longer battery life.

FIG. 2shows a break event management unit (BMU)18that can detect break events20and align them as coordinated break events22based on at least in part runtime information24associated with a platform/OS (operating system)26. The BMU18might be implemented in a module of the platform26, such as a system control unit (SCU) of a mobile Internet device (MID) platform or a platform controller hub (PCH) of a laptop platform. Indeed, the BMU18may reside in the operating system (OS) kernel space with slightly different interfaces and implementation techniques or in the user space. In the illustrated example, the runtime information24can be obtained from the sources28of the break events20as well as the platform26itself. For example, runtime information24obtained from a device coupled to the platform might include QoS (quality of service) specifications that identify a maximum delay time for one or more IO events. In addition, runtime information24obtained from an application could identify a deferability characteristic of one or more timer events. For example, if a timer event is not deferrable, the BMU18may attempt to align other break events with the non-deferrable timer event. Otherwise, the BMU18could manage the timer events for optimal platform power saving and performance.

By way of example, if an application requests that a timer event occur every 50 ms, deferrable to a maximum frequency of every 100 ms, the BMU18may trigger the timer event every 100 ms while the platform26is relatively inactive. If the platform26becomes more active, however, due to break events generated by other sources, the BMU18could adapt the issuance of the timer event towards 50 ms for better application performance, without a negative impact on power consumption.

In addition, the platform26may provide runtime information24in the form of a low power state break even time, programmable performance requirements, and so on. The low power state break even time may indicate the amount of time the platform26should stay in a particular low power state in order to offset/amortize any power cost overhead associated with entering and exiting the low power state. As will be discussed in greater detail, the BMU18may use the low power state break even time to determine a holding time for each deferred break event. In this regard, power saving benefits may decline rapidly when the holding time becomes much longer than the break even time, while the performance can degrade significantly. Thus, the BMU18may determine a reasonable holding time based on the break even time and the desired performance.

The programmable performance requirements could be defined by a user of the platform26. Thus, if the user prefers higher performance, the holding time may be tuned downward to shorter values in order to provide faster response and improved performance (while potentially losing some power saving opportunities). If the user requests longer battery life, on the other hand, the holding time may be set to a relatively longer value in order to provide the platform26with more opportunity to remain in lower power states.

Turning now toFIG. 3, an exemplary method30of coordinating the issuance of break events is shown. The method30may be implemented in fixed-functionality hardware using circuit technology such as ASIC, complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, in executable software as a set of firmware and/or logic instructions stored in a machine- or computer-readable storage medium of a memory such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), flash memory, etc., or any combination thereof. Processing block32provides for collecting runtime information from devices, applications and the platform, and determining a holding time based on the runtime information. As already noted, the holding time determination may take into consideration low power break even times and programmable performance requirements, as well as maximum delay times for IO events and deferability characteristics of timer events.

If a break event is detected at block34, a determination may be made at block36as to whether the holding time has expired. If not, the break event can be deferred at block38. The deference of the break event could be achieved in a number of different ways depending on the circumstances. For example, the break event might be placed in a queue, wherein the queue could be collocated with the BMU18(FIG. 2), with the device issuing the break event, in a coalescing unit associated with the device, and so on. Indeed, if the break event is associated with a bus mastering transaction (e.g., DMA/direct memory access), the break event might be deferred by de-asserting a PCIe (Peripheral Components Interconnect Express) OBFF (opportunistic buffer flush/fill) signal to inform the source device that the PCIe bus is unavailable.

If either a non-deferrable break event is detected at block40or it is determined at block36that the holding time has expired, all deferred break events can be released/issued to the platform at block42. Illustrated block44provides for scheduling the next holding time based on the collected runtime information. As already noted, the holding time can be adjusted dynamically. The platform power management unit can be informed of the next holding time at block46.

FIG. 4shows a system48in which a BMU50is coupled to a processor/platform52that receives various break events from application timers54and devices56(56a-56c), wherein the break events can cause the processor/platform52to exit (or prevent entry to) one or more low power states. In the illustrated example, the coalescing units58can be used to reduce the number of break events by, for example, combining multiple packets that might otherwise result in multiple break events, into a single break event. The coalescing units58may therefore be particularly useful for communication devices such as network controllers, although other devices and applications may also benefit from the coalescing process.

Starting from the initialization phase at boot time, the coalescing units58can obtain, or may already be aware of, system parameters such as override policies, device buffer sizes, device latency tolerance requirements, etc. These parameters can be used by the coalescing units58to determine an initial device/application-based holding time, which can later be adjusted based on the runtime behavior, as needed. During the runtime, the coalescing units58may track each break event capable device to determine whether the device has been quiet for a pre-determined period of time (e.g., no interrupts generated for the last α ms). Upon such inactivity, the coalescing unit58in question can enter a holding interval (e.g., for β ms), within which no interrupts from this particular source will be relayed up to the BMU50and/or processor/platform52. This approach may be implemented on a per-device/application basis and with different parameters for each device/application. In addition, certain strategies may be used to bypass the coalescing unit58, such as high-performance/benchmarking modes, etc.

While the coalescing units58could be implemented in the devices56and application timer54, locating them in the BMU50may be more scalable by eliminating any need for device manufacturers to support break event alignment. Implementing the coalescing unit58in the BMU50may involve ensuring that the upper limit of the holding timer β is compatible with the device's internal buffer size in order to prevent buffer overruns. In addition, the inactivity timer α can be set to a large enough value so as to prevent premature expiration and any negative impact on maximum system performance.

A number of different strategies may be used for coalescing timer adaptation. For example, a “static policy” might involve linking the coalescing behavior to a user-set (or OS profile-based) system preferences. Thus, if a high-performance profile is preferred by the user, coalescing might be bypassed with β=0. For a balanced performance/power profile, a typical value of β=5 ms could be selected. For a low-power mode, with maximum power savings, a typical value of β=10 ms may be selected. Alternatively, a “dynamic policy” could be used in which β is controlled on a closed-loop basis, based on the average break event count observed over a certain counting period. The approach could therefore make the coalescing as non-intrusive as possible, so that the break event behavior (on the average sense) does not change significantly. Starting from a typically small β value, the number of break events from individual devices can be observed over relatively longer periods (i.e., on the order of seconds) of time, and β may be additively increased until the average number of events change significantly. Depending on the change, β could either reset to be adapted from scratch or multiplicatively decreased.

Turning now toFIG. 5, a system60is shown. The system60may be part of a mobile platform having computing functionality (e.g., personal digital assistant/PDA, laptop), communications functionality (e.g., wireless smart phone), imaging functionality, media playing functionality, or any combination thereof (e.g., mobile Internet device/MID). In the illustrated example, the system60includes a processor62, an integrated memory controller (IMC)74, an IO module64, system memory66, a network controller (e.g., network interface card)68, an audio IO device72, a solid state disk (SSD)70, and one or more other controllers80. The processor62, which may include a core region with one or several processor cores76, may use a power management unit (PMU)78to place its cores76and other system components into one or more active and/or idle states based on performance and/or power management concerns, as already noted.

The illustrated IO module64, sometimes referred to as a Southbridge or South Complex of a chipset, functions as a host device and communicates with the network controller68, which could provide off-platform communication functionality for a wide variety of purposes such as cellular telephone (e.g., W-CDMA (UMTS), CDMA2000 (IS-856/IS-2000), etc.), WiFi (e.g., IEEE 802.11, 1999 Edition, LAN/MAN Wireless LANS), Bluetooth (e.g., IEEE 802.15.1-2005, Wireless Personal Area Networks), WiMax (e.g., IEEE 802.16-2004, LAN/MAN Broadband Wireless LANS), Global Positioning System (GPS), spread spectrum (e.g., 900 MHz), and other radio frequency (RF) telephony purposes. The IO module64may also include one or more wireless hardware circuit blocks to support such functionality.

The SSD70may include one or more NAND chips and might be used to provide high capacity data storage and/or a significant amount of parallelism. There may also be solutions that include NAND controllers implemented as separate application specific integrated circuit (ASIC) controllers being connected to the IO module64on standard buses such as a Serial ATA (SATA, e.g., SATA Rev. 3.0 Specification, May 27, 2009, SATA International Organization/SATA-IO) bus, or a PCI Express Graphics (PEG, e.g., Peripheral Components Interconnect/PCI Express x16 Graphics 150W-ATX Specification 1.0, PCI Special Interest Group) bus. The SSD70could also be used as a USB (Universal Serial Bus, e.g., USB Specification 2.0, USB Implementers Forum) flash storage device.

The illustrated IO module64includes a BMU82that is configured to detect break events from a plurality of different sources such as the network controller68, audio IO device72, SSD70, active applications executing on the processor62, etc., and coordinate issuance of the break events to the processor62based on runtime information associated with the system60. In one example, coordinating issuance of the break events includes determining a holding time based on the runtime information and deferring at least one of the break events based on the holding time. For example, the system60might execute a VoIP (voice over Internet Protocol) application in which the network controller68and the audio IO device72each actively generate IO events little or no regard for the IO events generated by the other device. By using the BMU82to coordinate the break events from the network controller68and audio IO device72, the illustrated IO module64can enable the components of the system60to enter deeper low power states for longer periods of time, and therefore significantly enhance the power savings achieved by the system60.

Thus, the above techniques can provide a holistic approach to defining computing system architectures and interfaces so that they coordinate and align activities of multiple IO devices and applications. As a result, platform idleness may be maximized for optimal platform power saving. In addition, such coordination and alignment could enable the platform to more closely approximate an ideal “work-load proportional” power consumption with robust performance.