Date: Tue, 23 Aug 2016 07:41:47 -0400 From: Eric McCorkle <eric@metricspace.net> To: Warner Losh <imp@bsdimp.com>, "Conrad E. Meyer" <cem@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: Info about suspend-to-disk Message-ID: <60cd4f2c-13a8-3fc1-5f5d-c442cafc6e80@metricspace.net> In-Reply-To: <CANCZdfpUc_14oLthrSVPX%2BQvoOKOhEB=CgHXCAzkiMT=kcn-bA@mail.gmail.com> References: <141b1050-8fb5-e8c7-0e0f-50607f2f28b9@metricspace.net> <CAG6CVpXxsbOQqOiytcrFSp486Cdzu9ny8HQmG=nzq_r-fhce0Q@mail.gmail.com> <CANCZdfpUc_14oLthrSVPX%2BQvoOKOhEB=CgHXCAzkiMT=kcn-bA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q2L3ShLS7gPJBFLPslcesXsAi6hlKQbQu Content-Type: multipart/mixed; boundary="SWqjJvR0GAtMkxrs2k69KFstwmlb4ug0H" From: Eric McCorkle <eric@metricspace.net> To: Warner Losh <imp@bsdimp.com>, "Conrad E. Meyer" <cem@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <hackers@freebsd.org> Message-ID: <60cd4f2c-13a8-3fc1-5f5d-c442cafc6e80@metricspace.net> Subject: Re: Info about suspend-to-disk References: <141b1050-8fb5-e8c7-0e0f-50607f2f28b9@metricspace.net> <CAG6CVpXxsbOQqOiytcrFSp486Cdzu9ny8HQmG=nzq_r-fhce0Q@mail.gmail.com> <CANCZdfpUc_14oLthrSVPX+QvoOKOhEB=CgHXCAzkiMT=kcn-bA@mail.gmail.com> In-Reply-To: <CANCZdfpUc_14oLthrSVPX+QvoOKOhEB=CgHXCAzkiMT=kcn-bA@mail.gmail.com> --SWqjJvR0GAtMkxrs2k69KFstwmlb4ug0H Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/23/16 01:30, Warner Losh wrote: >>> * Modify boot1 to check for saved images. Load and resume if one exi= sts. >> >> 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.) >=20 > 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... My only reservation about loader is that users will likely want the system to come back up quickly, as if resuming. Dropping them into the loader menu might not be what they want/expect. If it ends up being done in loader, it might be worth having a "fast-path" option that skips the usual menu. Actually, the "fast-path" loader option might be a worthwhile feature generally, for people who just want fast boot times. >>> * Do the codepaths currently exist to allow dump functionality to wri= te >>> 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. >=20 > 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... Does suspend-to-swap wipe out what's already stored there? Since you plan on coming back online, you'd want to preserve all contents of swap. In any case, I could see it failing if there's not enough free space in swap (which I guess would also be a possibility with suspend-to-file) If dump to swap does preserve the contents of swap, it might be better to do it that way first to work out all the other issues. >>> * What would be the most sensible default behavior for device >>> hibernate/unhibernate methods? >=20 > 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. Wouldn't there need to be some extra re-initialization for deeper power states? In the worst case scenario, you're coming back online from a hard power-off, so I'd imagine you'd want another codepath. --SWqjJvR0GAtMkxrs2k69KFstwmlb4ug0H-- --Q2L3ShLS7gPJBFLPslcesXsAi6hlKQbQu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EARYIAAYFAle8NnsACgkQVsKIQKqABI2NVgD/SwuiyE4nK9QYAPzo0HOgftnR KGsEB2Ed7WqB0ZQa+OUA/1YANu2SOrRU6fKWmwKdbAqd1R4bxaKzg4mYH4ab2ToK =SMqK -----END PGP SIGNATURE----- --Q2L3ShLS7gPJBFLPslcesXsAi6hlKQbQu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?60cd4f2c-13a8-3fc1-5f5d-c442cafc6e80>