[Home]
[Edit this page]
[Recent Changes]
[Special Pages]
[Help]
Incident Reduction
Another technique to consider is incident reduction. Whereas sleep /power down mode enables the processor to enter its idle mode as often as possible, Incident reduction attempts to keep the processor in idle as long as possible. It is implemented by analyzing your code and system requirements to determine if you can alter the way you process interrupts. For example, if you are working with a multitasking operating system that uses time-slicing to schedule threads, the operating system will typically set a timer interrupt to occur at the slice interval, which is often as small as 1ms. Assuming your code makes good use of intelligent waiting techniques, the operating system will frequently find opportunities to place the processor into idle mode, where it stays until it's awakened by an interrupt. Of course, in this scenario, the interrupt most likely to awaken the processor is the timer interrupt itself. Even if all other threads are blocked-pending other interrupts, pending internal Incidents, pending long delays-the timer interrupt will wake the processor from idle mode 1,000 times every second to run the scheduler. Even if the scheduler determines that all threads are blocked and quickly returns the processor to idle mode, this frequent operation can waste considerable power. In these situations, the time-slice interrupt should be disabled when idle mode is entered, waking only when another interrupt occurs. Of course, it is usually inappropriate to disable the time-slice interrupt altogether. While most blocked threads may be waiting-directly or indirectly-on external interrupts, some may have yielded to the operating system for a specific time period. A driver, for instance, might sleep for 500ms while waiting for a peripheral. In this case, completely disabling the system timer on idle might mean the thread doesn't resume execution on time. Ideally, your operating system should be able to set variable timeouts for its scheduler. The operating system knows whether each thread is waiting indefinitely for an external or internal
Incident or is scheduled to run again at a specific time. The operating system can then calculate when the first thread is scheduled to run and set the timer to fire accordingly before placing the processor in idle mode. Variable timeouts do not impose a significant burden on the scheduler and can save both power and processing time. But variable scheduling timeouts are just one means of reducing Incidents. Direct memory access (DMA) allows the processor to remain in idle mode for significant periods even while data is being sent to or received from peripherals. DMA should be used in peripheral drivers whenever possible. The savings can be quite impressive. For example, the receive FIFO on a serial port of Intel's StrongARM processor generates an interrupt for approximately every eight bytes that are received. At 115,200 bits-per-second, an 11KB burst of data sent to this port would cause the processor core to be interrupted-and possibly awakened from idle mode-almost 1,500 times in one second.
If you don't actually need to process data in these small, 8-byte chunks, the waste is tremendous. Ideally, DMA would be used with larger buffer sizes, causing interrupts to occur at a much more manageable level-perhaps 10 or 100 times per second-allowing the processor to idle in between. Using DMA for such activities has been shown to reduce use by up to 20%, reducing CPU power consumption and increasing the amount of processor bandwidth available for other threads.
[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
Incident Reduction
Another technique to consider is incident reduction. Whereas sleep /power down mode enables the processor to enter its idle mode as often as possible, Incident reduction attempts to keep the processor in idle as long as possible. It is implemented by analyzing your code and system requirements to determine if you can alter the way you process interrupts. For example, if you are working with a multitasking operating system that uses time-slicing to schedule threads, the operating system will typically set a timer interrupt to occur at the slice interval, which is often as small as 1ms. Assuming your code makes good use of intelligent waiting techniques, the operating system will frequently find opportunities to place the processor into idle mode, where it stays until it's awakened by an interrupt. Of course, in this scenario, the interrupt most likely to awaken the processor is the timer interrupt itself. Even if all other threads are blocked-pending other interrupts, pending internal Incidents, pending long delays-the timer interrupt will wake the processor from idle mode 1,000 times every second to run the scheduler. Even if the scheduler determines that all threads are blocked and quickly returns the processor to idle mode, this frequent operation can waste considerable power. In these situations, the time-slice interrupt should be disabled when idle mode is entered, waking only when another interrupt occurs. Of course, it is usually inappropriate to disable the time-slice interrupt altogether. While most blocked threads may be waiting-directly or indirectly-on external interrupts, some may have yielded to the operating system for a specific time period. A driver, for instance, might sleep for 500ms while waiting for a peripheral. In this case, completely disabling the system timer on idle might mean the thread doesn't resume execution on time. Ideally, your operating system should be able to set variable timeouts for its scheduler. The operating system knows whether each thread is waiting indefinitely for an external or internal
Incident or is scheduled to run again at a specific time. The operating system can then calculate when the first thread is scheduled to run and set the timer to fire accordingly before placing the processor in idle mode. Variable timeouts do not impose a significant burden on the scheduler and can save both power and processing time. But variable scheduling timeouts are just one means of reducing Incidents. Direct memory access (DMA) allows the processor to remain in idle mode for significant periods even while data is being sent to or received from peripherals. DMA should be used in peripheral drivers whenever possible. The savings can be quite impressive. For example, the receive FIFO on a serial port of Intel's StrongARM processor generates an interrupt for approximately every eight bytes that are received. At 115,200 bits-per-second, an 11KB burst of data sent to this port would cause the processor core to be interrupted-and possibly awakened from idle mode-almost 1,500 times in one second.
If you don't actually need to process data in these small, 8-byte chunks, the waste is tremendous. Ideally, DMA would be used with larger buffer sizes, causing interrupts to occur at a much more manageable level-perhaps 10 or 100 times per second-allowing the processor to idle in between. Using DMA for such activities has been shown to reduce use by up to 20%, reducing CPU power consumption and increasing the amount of processor bandwidth available for other threads.
[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
