Slides for my presentation on the Linux suspend to disk implementation are here. The presentation itself should be linked off the programme at some point, but for now here's a representative preview slide:
(Post a new comment)
(Reply to this)
(Reply to this) (Thread)
Suspend to DiskWhy it doesn't work, can't work and never worked in the first place(and what to do about it)Matthew Garrett<mjg59@srcf.ucam.org>This presentation contains no drosophilaWhat is suspend to disk?Save system state to diskReboot directly into saved stateConsumes no power when suspendedHigher latency in resumeHow does suspend to disk work?Freeze processesSuspend devicesCopy stateRestore devicesSave state to diskPower downCakeThe cake is a lieFreezer nightmareWhat else can go wrong?Your swap is on a FUSE filesystemYou have userspace USB driversYour network driver blocks while scanningNFS(Without loss of generality)Why do we use the freezer?Because we're suspending using the same kernel as we were runningHow can we avoid this?Use a different kernel?KexecFunctionality for loading a new kernel and executing itKexecing a new kernel is an atomic operationNew kernel can save state to disk without interfering with the “real” kernelHas its own i/o paths, working with its own RAMYing Huang at Intel working on thisStill stuck with the freezer...Drivers assume that userspace will be frozen(Silly drivers)But those need to be fixed anyway, so hurrahWarning: next slide contains crackDo we really want to suspend to disk?Users just want to retain stateCheckpointing applications handles a lot of thisSaving hardware state more awkwardBut buys us more functionalitySummary:The freezer is unreliable and cannot sensibly be made reliableSuspend to disk must be a reliable processTherefore we need to remove the need for the freezer(Cake)Please hire meI'm lovely, really
(Reply to this) (Parent)
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
