From owner-freebsd-hackers@freebsd.org Tue Aug 23 05:30:39 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27AD4BC3EED for ; Tue, 23 Aug 2016 05:30:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0597E16A3 for ; Tue, 23 Aug 2016 05:30:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 04FCBBC3EEC; Tue, 23 Aug 2016 05:30:39 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04A99BC3EEB for ; Tue, 23 Aug 2016 05:30:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6D7B16A2 for ; Tue, 23 Aug 2016 05:30:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x232.google.com with SMTP id f6so117475488ith.0 for ; Mon, 22 Aug 2016 22:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rMf/E3o7PzX2BfpbOm+q7lY/FjcYm16vb/NKqYcSCEY=; b=0b8CJJmOSeHm0wqrfZBd9Qp4jNIDhzb3nquk7NFaSKDt3iFXVEnj8j8p70o3wpygAo hbKUxVZ1PkO+aZUeSjS7e92CEvUT4i9/By4q2rfHrdxAKDQY/jaLEP/9CyovRd/nabP0 xS7ticdT3/6+kmsWgZIIxsMoLQ/DJkNgPjvW9NUiXuPkNmXiCmsEFSDCUFQ/zaYNIPqk ciAfnfy2cRJXyBFrHdzUnFrQ54NEgfbnLBPZ63LsjVnWzaEHpYuKs9zy1ekzQbhd2brD ElIwidL4X8fVvMun+dVVxtf893foN+R4MOT0YM8noqqP5nt1/s1yClXmM+AB82x+DPpa 6+Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rMf/E3o7PzX2BfpbOm+q7lY/FjcYm16vb/NKqYcSCEY=; b=f1pDi17Kek+/kLR5mZoiBt9ZFgfQ7+LCu5zjpnmsxEF4c6uDsLG8AcDSP/zE1FW2+7 4qbL63y/5Sy8y62mWgb/TOHHnG7Akcc9E5OR2vCr+J+rdc46xBayTNSDrLZLnv9EaUJn TdJDSye0fi674n2YKOVi4fOK3gpH7pwRhU0Z3QHQ2P+js+D1zYvPtWA8olR/6GlXgca6 FE05l9kYtS/YFZM+9OtgJqqmcS1sq1JrdOwSkUxO20c9s8mxzmtj8vXZRrJ9yMqHGZmZ z0DgXQHLO2ZN926Qm1qeGf+jZsHbfDCxqJrAHyyQ9hOcqE444IQ0qkKuJiZuzIBz4z52 hBJQ== X-Gm-Message-State: AEkoouupgThI+kBVB1Ph4hvyCFUqCInosHY7IEREh2aWUY9TewTa49nGACj6eZTLyUTYfi1K88SV6DqEmOSCBA== X-Received: by 10.107.9.39 with SMTP id j39mr27095255ioi.73.1471930238199; Mon, 22 Aug 2016 22:30:38 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.36.65.7 with HTTP; Mon, 22 Aug 2016 22:30:37 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <141b1050-8fb5-e8c7-0e0f-50607f2f28b9@metricspace.net> From: Warner Losh Date: Mon, 22 Aug 2016 23:30:37 -0600 X-Google-Sender-Auth: C47lZUkYLGHjE1UnNn39mKUMqqw Message-ID: Subject: Re: Info about suspend-to-disk To: "Conrad E. Meyer" Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 05:30:39 -0000 On Mon, Aug 22, 2016 at 11:14 PM, Conrad Meyer wrote: > Hi Eric, > > On Mon, Aug 22, 2016 at 8:41 PM, Eric McCorkle 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