From: "Rafael J. Wysocki" <rjw@sisk.pl> To: Ian Campbell <ijc@hellion.org.uk> Cc: Alan Stern <stern@rowland.harvard.edu>, Brendan Cully <brendan@cs.ubc.ca>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, LKML <linux-kernel@vger.kernel.org>, "linux-pm@lists.linux-foundation.org" <linux-pm@lists.linux-foundation.org>, "SUZUKI, Kazuhiro" <kaz@jp.fujitsu.com> Subject: Re: [Xen-devel] Re: [linux-pm] [PATCH 0/2] Fix hangup after creating checkpoint on Xen. Date: Thu, 10 Feb 2011 18:01:20 +0100 [thread overview] Message-ID: <201102101801.20345.rjw@sisk.pl> (raw) In-Reply-To: <1297355688.21980.488.camel@zakaz.uk.xensource.com> On Thursday, February 10, 2011, Ian Campbell wrote: > On Thu, 2011-02-10 at 11:00 -0500, Alan Stern wrote: > > On Thu, 10 Feb 2011, Ian Campbell wrote: > > > > > On Wed, 2011-02-09 at 23:42 +0000, Alan Stern wrote: > > > > In fact there already is a "fast suspend & resume" path in the PM core. > > > > It's the freeze/thaw procedure used when starting to hibernate. The > > > > documentation specifically says that drivers' freeze methods are > > > > supposed to quiesce their devices but not change power levels. In > > > > addition, the thaw method is invoked as part of recovery from a failed > > > > hibernation attempt, so it already has the "cancel" semantics that xen > > > > seems to want. > > > > > > Sounds like that would work and I would much prefer to simply make > > > correct use of the core functionality. > > > > It seems like a reasonable approach. Whether it will actually _work_ > > is a harder question... :-) > > Heh. > > > > So PMSG_FREEZE is balanced by either PMSG_RECOVER or PMSG_THAW depending > > > on whether the suspend was cancelled or not? > > > > Basically yes. It is also "balanced" by PMSG_RESTORE, which is used > > after a memory image has been restored (although this isn't relevant to > > your snapshotting). See the comments in include/linux/pm.h. > > The documentation of the individual events in pm.h is good. Is there a > reference for the sequence of events for the different types of > suspend/hibernate/etc? > > > > So the sequence of events > > > is something like: > > > dpm_suspend_start(PMSG_FREEZE); > > > > > > dpm_suspend_noirq(PMSG_FREEZE); > > > > > > sysdev_suspend(PMSG_QUIESCE); > > > > This should say sysdev_suspend(PMSG_FREEZE). > > > > > cancelled = suspend_hypercall() > > > > At this point swsusp_arch_suspend() is called. If that translates to > > suspend_hypercall() in your setting, then yes. > > > > > sysdev_resume(); > > > > > > dpm_resume_noirq(cancelled ? PMSG_RECOVER : PMSG_THAW); > > > > > > dpm_resume_end(cancelled ? PMSG_RECOVER : PMSG_THAW); > > > ? > > > > Yes. > > Both of those call ->thaw ->complete. Did I mean "cancelled ? > PMSG_THAW : PMSG_RESTORE"? (or s/THAW/RECOVER?) > > If the suspend was cancelled then we want the devices to simply pickup > where they were before the freeze, wereas if we really did suspend (or > migrate or whatever) then they need to do a more complete reset and > reconnect operation so we want some sort of indication to the driver > which happened. In that case you should probably use PMSG_THAW (or PMSG_RECOVER) for the "cancel" case and PMSG_RESTORE for the "success" case (pretty much what hibernation does). And please don't forget to update the comments in pm.h to cover your usage case. :-) > > > (For comparison we currently have: > > > > > > dpm_suspend_start(PMSG_SUSPEND); > > > > > > > > > > > > dpm_suspend_noirq(PMSG_SUSPEND); > > > > > > > > > > > > sysdev_suspend(PMSG_SUSPEND); > > > > > > /* suspend hypercall */ > > > > > > sysdev_resume(); > > > > > > > > > > > > dpm_resume_noirq(PMSG_RESUME); > > > > > > > > > > > > dpm_resume_end(PMSG_RESUME); > > > ) > > > > Right. The sequence of calls is the same, but the PMSG_ argument is > > different so drivers are expected to act differently in response. > > The drivers don't actually see the PMSG_* though right? They only see a > differing sequence of hooks from dev_pm_ops called. That's correct. Thanks, Rafael
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@sisk.pl> To: Ian Campbell <ijc@hellion.org.uk> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, LKML <linux-kernel@vger.kernel.org>, Brendan Cully <brendan@cs.ubc.ca>, Alan Stern <stern@rowland.harvard.edu>, "linux-pm@lists.linux-foundation.org" <linux-pm@lists.linux-foundation.org>, "SUZUKI, Kazuhiro" <kaz@jp.fujitsu.com> Subject: Re: Re: [linux-pm] [PATCH 0/2] Fix hangup after creating checkpoint on Xen. Date: Thu, 10 Feb 2011 18:01:20 +0100 [thread overview] Message-ID: <201102101801.20345.rjw@sisk.pl> (raw) In-Reply-To: <1297355688.21980.488.camel@zakaz.uk.xensource.com> On Thursday, February 10, 2011, Ian Campbell wrote: > On Thu, 2011-02-10 at 11:00 -0500, Alan Stern wrote: > > On Thu, 10 Feb 2011, Ian Campbell wrote: > > > > > On Wed, 2011-02-09 at 23:42 +0000, Alan Stern wrote: > > > > In fact there already is a "fast suspend & resume" path in the PM core. > > > > It's the freeze/thaw procedure used when starting to hibernate. The > > > > documentation specifically says that drivers' freeze methods are > > > > supposed to quiesce their devices but not change power levels. In > > > > addition, the thaw method is invoked as part of recovery from a failed > > > > hibernation attempt, so it already has the "cancel" semantics that xen > > > > seems to want. > > > > > > Sounds like that would work and I would much prefer to simply make > > > correct use of the core functionality. > > > > It seems like a reasonable approach. Whether it will actually _work_ > > is a harder question... :-) > > Heh. > > > > So PMSG_FREEZE is balanced by either PMSG_RECOVER or PMSG_THAW depending > > > on whether the suspend was cancelled or not? > > > > Basically yes. It is also "balanced" by PMSG_RESTORE, which is used > > after a memory image has been restored (although this isn't relevant to > > your snapshotting). See the comments in include/linux/pm.h. > > The documentation of the individual events in pm.h is good. Is there a > reference for the sequence of events for the different types of > suspend/hibernate/etc? > > > > So the sequence of events > > > is something like: > > > dpm_suspend_start(PMSG_FREEZE); > > > > > > dpm_suspend_noirq(PMSG_FREEZE); > > > > > > sysdev_suspend(PMSG_QUIESCE); > > > > This should say sysdev_suspend(PMSG_FREEZE). > > > > > cancelled = suspend_hypercall() > > > > At this point swsusp_arch_suspend() is called. If that translates to > > suspend_hypercall() in your setting, then yes. > > > > > sysdev_resume(); > > > > > > dpm_resume_noirq(cancelled ? PMSG_RECOVER : PMSG_THAW); > > > > > > dpm_resume_end(cancelled ? PMSG_RECOVER : PMSG_THAW); > > > ? > > > > Yes. > > Both of those call ->thaw ->complete. Did I mean "cancelled ? > PMSG_THAW : PMSG_RESTORE"? (or s/THAW/RECOVER?) > > If the suspend was cancelled then we want the devices to simply pickup > where they were before the freeze, wereas if we really did suspend (or > migrate or whatever) then they need to do a more complete reset and > reconnect operation so we want some sort of indication to the driver > which happened. In that case you should probably use PMSG_THAW (or PMSG_RECOVER) for the "cancel" case and PMSG_RESTORE for the "success" case (pretty much what hibernation does). And please don't forget to update the comments in pm.h to cover your usage case. :-) > > > (For comparison we currently have: > > > > > > dpm_suspend_start(PMSG_SUSPEND); > > > > > > > > > > > > dpm_suspend_noirq(PMSG_SUSPEND); > > > > > > > > > > > > sysdev_suspend(PMSG_SUSPEND); > > > > > > /* suspend hypercall */ > > > > > > sysdev_resume(); > > > > > > > > > > > > dpm_resume_noirq(PMSG_RESUME); > > > > > > > > > > > > dpm_resume_end(PMSG_RESUME); > > > ) > > > > Right. The sequence of calls is the same, but the PMSG_ argument is > > different so drivers are expected to act differently in response. > > The drivers don't actually see the PMSG_* though right? They only see a > differing sequence of hooks from dev_pm_ops called. That's correct. Thanks, Rafael
next prev parent reply other threads:[~2011-02-10 17:01 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-02-07 9:07 [PATCH 0/2] Fix hangup after creating checkpoint on Xen SUZUKI, Kazuhiro 2011-02-07 9:08 ` [PATCH 1/2] " SUZUKI, Kazuhiro 2011-02-07 9:08 ` SUZUKI, Kazuhiro 2011-02-07 9:08 ` [PATCH 2/2] " SUZUKI, Kazuhiro 2011-02-07 9:08 ` SUZUKI, Kazuhiro 2011-02-07 9:35 ` [PATCH 0/2] " Rafael J. Wysocki 2011-02-08 11:22 ` Ian Campbell 2011-02-08 11:22 ` Ian Campbell 2011-02-08 16:46 ` Alan Stern 2011-02-08 16:46 ` [linux-pm] " Alan Stern 2011-02-08 16:46 ` Alan Stern 2011-02-08 17:35 ` Ian Campbell 2011-02-08 17:35 ` Ian Campbell 2011-02-09 23:16 ` Brendan Cully 2011-02-09 23:16 ` Brendan Cully 2011-02-09 23:42 ` Alan Stern 2011-02-09 23:42 ` Alan Stern 2011-02-10 11:40 ` [Xen-devel] " Ian Campbell 2011-02-10 11:40 ` [Xen-devel] Re: [linux-pm] " Ian Campbell 2011-02-10 11:40 ` Ian Campbell 2011-02-10 16:00 ` [Xen-devel] " Alan Stern 2011-02-10 16:00 ` [Xen-devel] Re: [linux-pm] " Alan Stern 2011-02-10 16:00 ` Alan Stern 2011-02-10 16:26 ` [Xen-devel] " Rafael J. Wysocki 2011-02-10 16:26 ` Rafael J. Wysocki 2011-02-10 16:26 ` [Xen-devel] " Rafael J. Wysocki 2011-02-10 16:34 ` Ian Campbell 2011-02-10 16:34 ` [Xen-devel] Re: [linux-pm] " Ian Campbell 2011-02-10 16:34 ` Ian Campbell 2011-02-10 17:01 ` Rafael J. Wysocki [this message] 2011-02-10 17:01 ` Rafael J. Wysocki 2011-02-17 7:56 ` [PATCH] update comments in pm.h describing Xen Guest save/restore/checkpoint use case Shriram Rajagopalan 2011-02-17 7:56 ` Shriram Rajagopalan 2011-02-17 10:56 ` [Xen-devel] " Ian Campbell 2011-02-17 10:56 ` Ian Campbell 2011-02-10 17:01 ` [Xen-devel] Re: [PATCH 0/2] Fix hangup after creating checkpoint on Xen Rafael J. Wysocki 2011-02-10 18:56 ` [Xen-devel] Re: [linux-pm] " Alan Stern 2011-02-10 18:56 ` Alan Stern 2011-02-10 18:56 ` [Xen-devel] " Alan Stern 2011-02-09 23:42 ` Alan Stern 2011-02-10 11:31 ` [Xen-devel] Re: [linux-pm] " Ian Campbell 2011-02-10 11:31 ` Ian Campbell 2011-02-10 12:40 ` Ian Campbell 2011-02-10 19:31 ` Brendan Cully 2011-02-11 9:14 ` Ian Campbell 2011-02-11 9:37 ` Pasi Kärkkäinen 2011-02-11 9:51 ` Ian Campbell 2011-02-11 18:13 ` Shriram Rajagopalan 2011-02-14 9:15 ` Ian Campbell 2011-02-14 9:27 ` Ian Campbell 2011-02-10 17:53 ` [Xen-devel] " Brendan Cully 2011-02-10 17:53 ` [Xen-devel] Re: [linux-pm] " Brendan Cully 2011-02-10 17:53 ` Brendan Cully 2011-02-10 11:31 ` [Xen-devel] " Ian Campbell 2011-02-09 23:16 ` Brendan Cully 2011-02-08 17:35 ` Ian Campbell 2011-02-08 11:22 ` Ian Campbell 2011-02-07 9:35 ` Rafael J. Wysocki
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=201102101801.20345.rjw@sisk.pl \ --to=rjw@sisk.pl \ --cc=brendan@cs.ubc.ca \ --cc=ijc@hellion.org.uk \ --cc=kaz@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@lists.linux-foundation.org \ --cc=stern@rowland.harvard.edu \ --cc=xen-devel@lists.xensource.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.