Hi! > > > Actually the point I've been meaning to chime in on here is > > > that since, as Benjamin noted, if there's a "write to storage" > > > step (STD, not STR) it uses the "quiesced"/"frozen" system > > > state ... then the real problem is just that the current > > > framework **resumes way too many devices** when writing that > > > out to swap. (Which is a fourth step...) > > > > Ok, we need to dissect this a little more. > > > > From a conceptual level (not necessarily with this level of granularity in > > the methods drivers will have), for STD, we want to > > > > - Stop All Devices > > > > - Save Device State > > > > - Start swap device back up > > And right here, write the state to disk -- with records > indicating some state that help make resume work "better". > > An example would be the saved PCI state and the I/O queues > for the devices. Filesystems would presumably flush (and > maybe invalidate) caches in the "stop all devices" stage; > or would that be earlier still? It happens earlier still. Actually we only sys_sync(). Snapshot is atomic, that means that we do not need to care about I/O queues for devices etc. We could get away without sys_sync(). But sys_sync() is nice in case something goes wrong. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
