Peripheral State Persistence and Interrupt Management For Transiently Powered Systems Gautier Berthou, Tristan Delizy, Kevin Marquet, Tanguy Risset, Guillaume Salagnac Citi Lab, INSA Lyon, France NVMW, San Diego, March 12 th 2018
Context: Transiently Powered Systems Internet of Tiny Things • Internet of Things ◮ networked embedded systems • No battery ◮ harvest power RFID tags smart cards wearable sensors G. Berthou 2/23
Context: Program checkpointing Program Checkpointing: Power failure detection • Anticipate power failures Energy • Save program state to a Harvester RAM + buffer CPU non-volatile memory • Restore state on next boot NVM Power in ◮ Idea: add “OS” code to hide checkpointing to the application Supply voltage Vboot Vtrigger Vdeath Time Off time Lifecycles G. Berthou 3/23
Typical checkpoint structure Application state • Contains all relevant data to - Copy of variables enable application persistence - Copy of application stack - Copy of CPU registers • Stored in non-volatile memory G. Berthou 4/23
Checkpointing for Transiently Powered Systems Mementos [Ransford et al ’13] DINO [Lucia & Ransford ’15] HarvOS [Bhatti & Mottola ’16] Quickrecall [Jayakumar et al ’14] RAM CPU CPU NVRAM Flash RAM NV CPU NVRAM CPU NVRAM [Liu et al ’15] [Balsamo et al ’15, ’16] [Ait Aoudia et al ’14] G. Berthou 5/23
Outline Introduction: Context and State of the Art Peripheral State Persistence Peripheral State: Volatility Problem Peripheral Access: Atomicity Problem Interrupt handling Experimental Results Conclusion and perspectives G. Berthou 6/23
The Peripheral State Volatility Problem App Drv HW Application code rf send void main(void){ sensor_init(); rf_init(myconfig); for(;;){ v = sensor_read(); rf_send(v); ... } } Restoring memory content will not restore device state G. Berthou 7/23
Our approach: distinct roles for OS and drivers App OS Drv HW Each driver provides: • restore() function restore • device context Operating System: • checkpoints device contexts • calls every restore() function • checkpoints application state G. Berthou 8/23
The Peripheral Access Atomicity Problem App Drv HW Application code rf send void main(void){ sensor_init(); rf_init(myconfig); for(;;){ v = sensor_read(); rf_send(v); ... } } In most cases, resuming execution in the middle of a hardware access does not make sense G. Berthou 9/23
Our approach: make driver calls atomic Encapsulate driver functions into OS wrappers. Each driver provides a save() function that copies device context into checkpoint image. App OS Drv + HW On wrapper entry: • save arguments + function called wrapper • switch to volatile stack entry original driver On wrapper exit: function wrapper • save device contexts exit • clear arguments drv save() • switch back to application stack Interrupted driver calls are retried and not just resumed. G. Berthou 10/23
Outline Introduction: Context and State of the Art Peripheral State Persistence Peripheral State: Volatility Problem Peripheral Access: Atomicity Problem Interrupt handling Experimental Results Conclusion and perspectives G. Berthou 11/23
Interrupt-related problems Problems not specific to transiently-powered systems: • Concurrency • Race conditions ◮ Solution: critical sections with interrupts enabled. Specific to transiently-powered systems: • Interrupt data volatility G. Berthou 12/23
Interrupt data volatility Int. A App handler • Interrupt occurrence is Interrupt A volatile data. Peripheral • Peripheral data, e.g. , radio data is ready packet content, are also volatile data. G. Berthou 13/23
Our approach: extend solution to peripheral state volatility problem OS-managed top halves and user-managed bottom halves App OS Drv + HW • Each driver provides an on interrupt on_interrupt() routine. extracts data • Each top half calls the on_interrupt() routine of relevant drivers. drv save() save bottom scheduler half G. Berthou 14/23
Checkpoint structure Application state - Copy of variables - Copy of application stack - Copy of CPU registers OS state • OS and drivers states allow - Running driver call if any peripheral persistence - Address and arguments - Interrupt occurrence Drivers state - Driver A device context - Driver B device context - ... G. Berthou 15/23
Outline Introduction: Context and State of the Art Peripheral State Persistence Peripheral State: Volatility Problem Peripheral Access: Atomicity Problem Interrupt handling Experimental Results Conclusion and perspectives G. Berthou 16/23
Sytare Evaluation Setup Application void main(void){ syt_sensor_init(); syt_rf_init(myconfig); for(;;){ • MSP430FR5739: 16-bit v = syt_sensor_read(); CPU 24MHz, 1kB SRAM, compute(); syt_rf_send(v); 15kB FeRAM ... • RF-chip: CC2500 } } G. Berthou 17/23
Evaluation methodology Experimental setup Ground-truth • Varying parameter: lifecycle • Same application without OS duration layer • Stable supply without outage Supply voltage Vboot Vtrigger Vdeath Time Off time Lifecycles G. Berthou 18/23
Evaluation methodology Performance metrics • Duration of shortest usable lifecycle • Temporal execution efficiency x Lifecycle duration T GT Application runtime under Efficiency( x ) = T GT ground-truth conditions T ( x ) T ( x ) Application runtime with OS layer when the platform is ON G. Berthou 19/23
Efficiency results 1 0 . 8 Efficiency 0 . 6 0 . 4 0 . 2 T GT T min = 3 ms 0 0 200 400 600 800 1 , 000 Lifecycle duration (milliseconds) G. Berthou 20/23
Results: Driver call temporal overhead Driver calls are encapsulated into wrappers Driver call Overhead (%) Led toggle 1263 ADC read 27 Radio sleep 137 Radio wake-up 8 Radio send 1 G. Berthou 21/23
Outline Introduction: Context and State of the Art Peripheral State Persistence Peripheral State: Volatility Problem Peripheral Access: Atomicity Problem Interrupt handling Experimental Results Conclusion and perspectives G. Berthou 22/23
Conclusion and perspectives Peripheral State Persistence for Transiently Powered Systems • Volatility: device contexts • Atomicity: retry rather than resume • Interrupts: save data as soon as possible Project sources: https://gitlab.inria.fr/citi-lab/sytare-public Perspectives • Reduce overhead of driver calls • Adapt peripheral checkpointing to existing OS (RIOT, Contiki) • WCEC evaluation of peripheral accesses • Energy-based decision making G. Berthou 23/23
Checkpoint structure - Completed Application state - Copy of variables - Copy of application stack • Information about interrupt - Copy of CPU registers occurrence are kept in the OS OS state section of the checkpoint image. - Running driver call if any • Data carried by interrupts are - Address and arguments kept in the relevant device - Interrupt occurrence drivers. Ex: radio packet content Drivers state is owned by the radio chipset - Driver A device context driver. - Driver B device context - ... Last Current G. Berthou 0/-1
Complex driver call Sequence diagram SRAM state NVRAM Checkpoint NVRAM Checkpoint Next Image state Last Image state Modified App OS drv A drv B App Drivers App Drivers Kernel App Drivers Kernel drivers user main() App 0 A 0 B 0 ∅ ∅ A 0 B 0 ∅|∅ App 0 A 0 B 0 ∅|∅ syt drvA fn(x) App 1 A 0 B 0 ∅ ∅ A 0 B 0 ∅|∅ App 0 A 0 B 0 ∅|∅ drvA fn(x) App 1 A 0 B 0 ∅ ∅ A 0 B 0 drvA fn | x App 0 A 0 B 0 ∅|∅ drvB fn(y) App 1 A 1 B 0 ∅ ∅ A 0 B 0 drvA fn | x App 0 A 0 B 0 ∅|∅ mark dirty() App 1 A 1 B 1 { B } ∅ A 0 B 0 drvA fn | x App 0 A 0 B 0 ∅|∅ mark dirty() App 1 A 2 B 1 { B, A } ∅ A 0 B 0 drvA fn | x App 0 A 0 B 0 ∅|∅ drvB save() drvA save() App 1 A 2 B 1 ∅ ∅ A 2 B 1 ∅|∅ App 0 A 0 B 0 ∅|∅ App 2 A 2 B 1 ∅ ∅ A 2 B 1 ∅|∅ App 0 A 0 B 0 ∅|∅ Unmodified state Modified state G. Berthou 0/-1
Top halves and bottom halves Interrupt handling is split into OS-managed top halves and user-managed bottom halves. • Power loss is handled by top halves, making it possible to hide power loss from user. Design choices: two axes 1 Bottom half nestedness? No 2 Allowance of hardware operations being called from bottom halves ? Yes G. Berthou 0/-1
Data race conditions Application code static int x; bottom_half() { ++x; } main() { x = 0; ... if(x == 4) { ... } } G. Berthou -1/-1
Data race conditions Problem • Bottom halves may share data with user application: global variables. Solution • User-defined critical sections that disable bottom halves but keep interrupts enabled. • Bottom halves are delayed until the end of the critical section. • Interrupts are enabled, which makes the sytem reactive upon power loss detection. G. Berthou -1/-1
Peripheral access race conditions App OS Drv SPI syt spi config(A) spi config(A) Interrupt A Top half spi config(B) SPI has config A? G. Berthou -1/-1
Recommend
More recommend
