Tiny OS Optimistic Lightweight Interrupt Handler

1. Primitives Components Packet reception work breakdown Average Cost (cycles) Time (us) Percent CPU Utilization Normalized to byte copy Energy (nj/Bit) Byte copy AM 8 0.05% 0.20% 2 1 0.33 Packet Post an Event 10 1.12% 2.5 0.51% 1.25 7.58 Call a Command Ratio handler 26.87% 10 12.16% 10 182.38 1.25 Radio decode thread Post a Thread 5.48% 46 2.48% 11.5 6 37.2 Context Switch RFM 51 66.48% 30.08% 12.75 451.17 6 Interrupt (HW cost) Radio Reception - 9 - 2.25 1350 1 Idle Interrupt (SW cost) - 71 17.75 54.75% - 9 Total 100.00% 100.00% 2028.66 The Problem The Proposals Tiny OS Optimistic Lightweight Interrupt Handler • Tiny OS is an event-based Operating System environment for wireless network of deeply embedded systems. • Runs on low-power autonomous sensor nodes. -> Real need to cut power consumption. • Context switch is the most expensive software primitive in Tiny OS ->Reflected in the fact that most of the active execution cycles (>66%) are spent in RFM (lowest level component) during the reception of a packet. • Want to reduce the number of active cycles: reduce the RFM component’s work – make interrupts more effective. Optimistic (Lazy) Interrupt Handler: • Most of the time when an interrupt happens, the processor is in sleep mode (I.e., no thread is running at that time.) • If no thread is running when an interrupt happens, there is no need to save registers. • Solution: set aside a register, set it when the processor enters sleep mode. In the beginning of interrupts, check the flag and skip the saving and restoring of registers if the flag is set. //pseudo code: Void __interrupt__ ()(naked) { if (wasSleeping) { wasSleeping = FALSE; naked_interrupt(); } else { clothed_interrupt(); } } Void naked_interrupt()(naked){ // does work... asm (“reti”); } Void clothed_interrupt()(signal) { naked_interrupt(); } Software simulated register window: • TinyOS and application software typically uses about half of the available registers • Some registers can be reserved for interrupt handling • AVR has an asymmetric register set with some registers that are more general than others. Each resource pool must be partitioned separately to generate good code • Two variants of AVR compiler, each with own modified gcc backend to disallow use of certain registers • Registers used by other mode are marked as unspillable, fixed-use registers • Each mode has separate calling convention and low-level libraries • Post-compilation filter on interrupt-mode compiler • Interrupt handlers and their callee functions are extracted and renamed, then combined with output of user-mode compiler • Still a work in progress (compiled with user version gcc and interrupt version gcc, but linking is too slow). • Shared registers • Stack, Frame, indirect-PC address registers • User registers • R8-R15 cannot be used with immediate operands The Evaluation Network simulator: • Interrupt registers • R2-R7 cannot be used for immediate operands CPU simulator: Simon Yau (smyau@cs), Alan Shieh (ashieh@hkn.eecs). CS252, CS262A, Fall 200 • Used an existing AVR 8535 simulator. • Added simulated radio transceiver, LED, photo sensors to the simulator to make a simulated mote. • Take the following parameters during the reception of one packet (97 bits at 6Kbps, about 12.5us): • Number of cycles in sleep mode • Energy consumed. • Number of cycles in which interrupts are disabled. • Number of interrupts lost • Network simulation model • All motes simulated in lock-step • At each mote, the radio states of each in-range mote is compared to detect reception and collisions • Network state is propagated back into the mote simulators • Measure the number of interrupts that are lost. • Still work in progress. Lightweight Interrupt Handler: • With register window, the number of register available decreases -> increased pressure on register spills. • Need interrupt handlers that uses less register. • Can achieve this by delaying the handling of interrupts by posting a thread that fires off the event instead of firing it. • However, there is a catch: • Thread scheduler turned out to be the most register-intensive operation, therefore it must be re-written in assembly code before the lightweight interrupt handler is feasible. • It actually increases the handling time of events by adding thread posting/scheduling overhead and waste energy. • It would also help in cases where the interrupt handler wants to use some restricted registers which are not accessible to interrupt code. (e.g., reserved registers used for multiplications) Conclusions & Future work: • We must be very careful when designing the interrupt handler. For example, making the interrupt handler “lightweight” actually increases the workload of the CPU to a point where it will be too busy to take interrupts. • Investigate the impact of other fast context-switch mechanisms (e.g., shadow registers) using the simulation environment • Fully explore the design space of interrupt handlers. Timer_interrupt_thread Interrupt handler Interrupt handler Timing Diagram of Event Propagation Timing Diagram of Lightweight Event Propagation