Date: Mon, 22 Aug 2016 23:30:37 -0600 From: Warner Losh <imp@bsdimp.com> To: "Conrad E. Meyer" <cem@freebsd.org> Cc: Eric McCorkle <eric@metricspace.net>, "freebsd-hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: Info about suspend-to-disk Message-ID: <CANCZdfpUc_14oLthrSVPX%2BQvoOKOhEB=CgHXCAzkiMT=kcn-bA@mail.gmail.com> In-Reply-To: <CAG6CVpXxsbOQqOiytcrFSp486Cdzu9ny8HQmG=nzq_r-fhce0Q@mail.gmail.com> References: <141b1050-8fb5-e8c7-0e0f-50607f2f28b9@metricspace.net> <CAG6CVpXxsbOQqOiytcrFSp486Cdzu9ny8HQmG=nzq_r-fhce0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 22, 2016 at 11:14 PM, Conrad Meyer <cem@freebsd.org> wrote: > Hi Eric, > > On Mon, Aug 22, 2016 at 8:41 PM, Eric McCorkle <eric@metricspace.net> wrote: >> Hi everyone, >> >> I'm gathering information in preparation for possibly working on >> suspend-to-disk functionality. I have a fairly good idea of what it >> would take and one way to attack it. The overall plan would look >> something like this: >> >> * Use dump functionality to write an entire OS image out to disk. As >> this is a voluntary dump, it should be possible to go through the FS >> interface to produce a regular file. >> >> * Modify boot1 to check for saved images. Load and resume if one exists. > > That sort of thing should probably go in loader, not boot1. (boot0-2 > are just the MBR boot block(s), as I understand it; loader is the last > pre-OS stage and where most features live.) Generally, I concur. However, a lot will depend on the size of the binary that's needed to bring in the image. And the gymnastics to get everything back into the right PA space which might conflict with the PAs that are occupied by the loader... >> * Presumably there would need to be some new device methods added to do >> saving/reinitialization of devices. > > Probably similar problems to kexec/kboot. (That was a major roadblock > for kexec efforts, I believe.) I think getting this right will be the > really challenging part. There's already suspend/resume. Why aren't these hooks sufficient? >> The major open questions for me are the following: >> >> * Is there/has there been significant work in this direction? >> >> * Is there perhaps a better strategy? >> >> * Do the codepaths currently exist to allow dump functionality to write >> to a regular file in the case of a voluntary dump, or would this need to >> be added? > > That would have to be added. You could maybe register a file > dumperinfo (as long as you're careful to prevent its use on > panic-during-suspend), but nothing does this yet. Suspended, but not quite suspended might present problems because all filesystems need to have some threads running, but you don't want user threads changing state running. That's what makes suspend to file quite a bit more challenging than suspend to swap space... Suspend to swap space won't be too hard if you leverage the dump routines of all the drivers... >> * What would be the most sensible default behavior for device >> hibernate/unhibernate methods? We already have suspend / resume. There's been talk of augmenting these to allow for the more nuanced ways that ACPI suspends things vs the old APM. However, so far little urgent need has been seen to make progress on that because the simple ways still work. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpUc_14oLthrSVPX%2BQvoOKOhEB=CgHXCAzkiMT=kcn-bA>