Tiny OS Optimistic Lightweight Interrupt Handler Simon Yau Alan Shieh CS252, CS262A, Fall The Problem 1.Tiny OS is an event-based Operating System environment for wireless network of deeply embedded systems. 2.Runs on low-power autonomous sensor nodes. -> Real need to cut power consumption. 3.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. 4.Want to reduce the number of active cycles: reduce the RFM component’s work – make interrupts more effective. Components Packet reception work breakdown Percent CPU UtilizationEnergy (nj/Bit) AM 0.05%0.20%0.33 Packet 1.12%0.51%7.58 Ratio handler 26.87%12.16% Radio decode thread 5.48%2.48%37.2 RFM 66.48%30.08% Radio Reception Idle-54.75%- Total % Primitives Average Cost (cycles) Time (us) Normalized to byte copy Byte copy 821 Post an Event Call a Command Post a Thread Context Switch Interrupt (HW cost) Interrupt (SW cost) Lightweight Interrupt Handler: 1.With register window, the number of register available decreases -> increased pressure on register spills. 2.Need interrupt handlers that uses less register. 3.Can achieve this by delaying the handling of interrupts by posting a thread that fires off the event instead of firing it. 4.However, there is a catch: 1.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. 2.It actually increases the handling time of events by adding thread posting/scheduling overhead and waste energy. 5.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) Optimistic (Lazy) Interrupt Handler: 1.Most of the time when an interrupt happens, the processor is in sleep mode (I.e., no thread is running at that time.) 2.If no thread is running when an interrupt happens, there is no need to save registers. 3.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. The Evaluation 1.Used an existing AVR 8535 simulator. 2.Added simulated radio transceiver, LED, photo sensors to the simulator to make a simulated mote. 3.Take the following parameters during the reception of one packet (97 bits at 6Kbps, about 12.5us): 1.Number of cycles in sleep mode 2.Energy consumed. 3.Number of cycles in which interrupts are disabled. 4.Number of interrupts lost 1.Network simulation model 1.All motes simulated in lock-step 2.At each mote, the radio states of each in-range mote is compared to detect reception and collisions 3.Network state is propagated back into the mote simulators 2.Measure the number of interrupts that are lost. 3.Still work in progress. Network simulator: 1.TinyOS and application software typically uses about half of the available registers 1.Some registers can be reserved for interrupt handling 2.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 2.Two variants of AVR compiler, each with own modified gcc backend to disallow use of certain registers 1.Registers used by other mode are marked as unspillable, fixed-use registers 2.Each mode has separate calling convention and low-level libraries 3.Post-compilation filter on interrupt-mode compiler 1.Interrupt handlers and their callee functions are extracted and renamed, then combined with output of user-mode compiler 4.Still a work in progress (compiled with user version gcc and interrupt version gcc, but linking is too slow). Software simulated register window: R31 R30 R29 R28 R27 R26 R25 R24 R20-R23 R16-R19 R8-R15 R2-R7 R1 R0 Shared registers 1.Stack, Frame, indirect-PC address registers User registers 1.R8-R15 cannot be used with immediate operands Interrupt registers 1.R2-R7 cannot be used for immediate operands CPU simulator: The Proposals Timing Diagram of Lightweight Event Propagation Timing Diagram of Event Propagation Interrupt handler Timer_interrupt_thread //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(); } ConfigurationSleep Cycles (%)Energy (uJ)Interrupt-disabled Cycles(%) Lost Interrupt Original Interrupt Handler15.33% %0 Lightweight Interrupt Handler5.45% %100 Lazy Interrupt Handler28.95% %0 Conclusions & Future work: 1.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. 2.Investigate the impact of other fast context-switch mechanisms (e.g., shadow registers) using the simulation environment 3.Fully explore the design space of interrupt handlers.