Abstract: Systems and methods may provide for identifying a workload cycle for a computing platform, wherein the workload cycle is to include a busy duration and an idle duration. Additionally, platform energy consumption information may be determined for the workload cycle, and a frequency setting may be selected for the busy duration based at least in part on the platform energy consumption information.

Abstract: 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.

Abstract: 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.

Abstract: Systems and methods may provide for conducting a reward determination for a plurality of sleep states to obtain a plurality of reward determinations with respect to a device. In addition, a sleep state may be selected for the device from the plurality of sleep states based at least in part on the plurality of reward determinations. In one example, false entry and missed opportunity probabilities may be determined for stochastic interrupts, wherein the reward determination is conducted based at least in part on the false entry and missed opportunity probabilities.

Abstract: Systems and methods may provide for identifying runtime information associated with an active workload of a platform, and making an active idle state determination for the platform based on at least in part the runtime information. In addition, a low power state of a shared resource on the platform may be controlled concurrently with an execution of the active workload based on at least in part the active idle state determination.

Abstract: Methods and systems may provide for determining quality of service (QoS) information for a job associated with an application, and determining a condition prediction for a wireless channel of a mobile platform. Additionally, the job may be scheduled for communication over the wireless channel based at least in part on the QoS information and the condition prediction. In one example, scheduling the job includes imposing a delay in the communication if the condition prediction indicates that a throughput of the wireless channel is below a threshold and the delay complies with a latency constraint of the QoS information.

Abstract: 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.

Abstract: An intelligent cloud aware computing distribution architecture for a device. A network conditions monitor is to observe and identify decision impact factors of tasks in a runtime environment. A dynamic profiler, coupled to the network conditions monitor, is to receive runtime information regarding the decision impact factors identified by the network conditions monitor and produce a profile based on the decision impact factors. Runtime offload decision making logic is to process the profile produced by the dynamic profiler based on the received decision impact factors according a predetermined policy and to determine final offloading decisions based on the predetermined policy and the processed decision impact factors. The runtime offload decision making logic is to provide the final offloading decisions to the applications on the device for executing the tasks locally or remotely based on the determined final offloading decision.

Abstract: Systems and methods may provide for identifying a workload cycle for a computing platform, wherein the workload cycle is to include a busy duration and an idle duration. Additionally, platform energy consumption information may be determined for the workload cycle, and a frequency setting may be selected for the busy duration based at least in part on the platform energy consumption information.

Abstract: 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.

Abstract: A storage unit may have an associated processor and storage controller. The storage controller associated with the storage unit may store a mapping of objects (i.e., data) to blocks in the storage unit. This mapping may be received from another source, such as a file system, database, or software application, among other possibilities. The processor associated with the storage unit may execute operation s on the objects stored in the storage unit.

Abstract: Techniques are described for determining a temporary latency tolerance report (tLTR) value. A processing unit has to respond to a device interrupt within a duration specified by tLTR to ensure no incoming data is lost due to device buffer overflow. The tLTR value can be used to prevent the processing unit from entering too deep a sleep state when a device driver anticipates multiple sequential interrupts for a transaction.

Abstract: Systems and methods may provide for determining an absolute energy break-even time for a first low power state with respect to a current state of a system. A relative energy break-even time may also be determined for the first low power state with respect to a second low power state based on at least in part the absolute energy break-even time. In addition, an operating state may be selected for the system based on at least in part the relative energy break-even time.

Abstract: Techniques are described for determining a temporary latency tolerance report (tLTR) value. A processing unit has to respond to a device interrupt within a duration specified by tLTR to ensure no incoming data is lost due to device buffer overflow. The tLTR value can be used to prevent the processing unit from entering too deep a sleep state when a device driver anticipates multiple sequential interrupts for a transaction.

Abstract: 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.