From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: Christoph Hellwig <hch@lst.de>, rafael.j.wysocki@intel.com
Cc: Mario.Limonciello@dell.com, Keith Busch <kbusch@kernel.org>,
Keith Busch <keith.busch@intel.com>, Jens Axboe <axboe@fb.com>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme <linux-nvme@lists.infradead.org>,
Linux PM <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle
Date: Thu, 9 May 2019 14:48:59 +0800 [thread overview]
Message-ID: <064701C3-2BD4-4D93-891D-B7FBB5040FC4@canonical.com> (raw)
In-Reply-To: <20190509061237.GA15229@lst.de>
Cc Rafael and linux-pm
at 14:12, Christoph Hellwig <hch@lst.de> wrote:
> On Wed, May 08, 2019 at 08:28:30PM +0000, Mario.Limonciello@dell.com wrote:
>> You might think this would be adding runtime_suspend/runtime_resume
>> callbacks, but those also get called actually at runtime which is not
>> the goal here. At runtime, these types of disks should rely on APST which
>> should calculate the appropriate latencies around the different power
>> states.
>>
>> This code path is only applicable in the suspend to idle state, which
>> /does/
>> call suspend/resume functions associated with dev_pm_ops. There isn't
>> a dedicated function in there for use only in suspend to idle, which is
>> why pm_suspend_via_s2idle() needs to get called.
>
> The problem is that it also gets called for others paths:
>
> #ifdef CONFIG_PM_SLEEP
> #define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
> .suspend = suspend_fn, \
> .resume = resume_fn, \
> .freeze = suspend_fn, \
> .thaw = resume_fn, \
> .poweroff = suspend_fn, \
> .restore = resume_fn,
> #else
> else
> #define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
> #endif
>
> #define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
> const struct dev_pm_ops name = { \
> SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
> }
>
> And at least for poweroff this new code seems completely wrong, even
> for freeze it looks rather borderline.
Not really, for hibernation pm_suspend_via_s2idle() evaluates to false so
the old code path will be taken.
>
> And more to the points - if these "modern MS standby" systems are
> becoming common, which it looks they are, we need support in the PM core
> for those instead of working around the decisions in low-level drivers.
Rafael, what do you think about this?
Including this patch, there are five drivers that use
pm_suspend_via_{firmware,s2idle}() to differentiate between S2I and S3.
So I think maybe it’s time to introduce a new suspend callback for S2I?
>
>> SIMPLE_DEV_PM_OPS normally sets the same function for suspend and
>> freeze (hibernate), so to avoid any changes to the hibernate case it seems
>> to me that there needs to be a new nvme_freeze() that calls into the
>> existing
>> nvme_dev_disable for the freeze pm op and nvme_thaw() that calls into the
>> existing nvme_reset_ctrl for the thaw pm op.
>
> At least, yes.
Hibernation should remain the same as stated above.
>
>>> enterprise class NVMe devices
>>> that don't do APST and don't really do different power states at
>>> all in many cases.
>>
>> Enterprise class NVMe devices that don't do APST - do they typically
>> have a non-zero value for ndev->ctrl.npss?
>>
>> If not, they wouldn't enter this new codepath even if the server entered
>> into S2I.
>
> No, devices that do set NPSS will have at least some power states
> per definition, although they might not be too useful. I suspect checking
> APSTA might be safer, but if we don't want to rely on APST we should
> check for a power state supporting the condition that the MS document
> quoted in the original document supports.
If Modern Standby or Connected Standby is not supported by servers, I don’t
think the design documents mean much here.
We probably should check if the platform firmware really supports S2I
instead.
Kai-Heng
next prev parent reply other threads:[~2019-05-09 6:49 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-08 18:59 [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle Kai-Heng Feng
2019-05-08 19:15 ` Chaitanya Kulkarni
2019-05-08 19:16 ` Keith Busch
2019-05-08 19:30 ` Kai-Heng Feng
2019-05-08 19:38 ` Mario.Limonciello
2019-05-08 19:51 ` Christoph Hellwig
2019-05-08 20:28 ` Mario.Limonciello
2019-05-09 6:12 ` Christoph Hellwig
2019-05-09 6:48 ` Kai-Heng Feng [this message]
2019-05-09 6:52 ` Christoph Hellwig
2019-05-09 9:19 ` Rafael J. Wysocki
2019-05-09 9:25 ` Christoph Hellwig
2019-05-09 20:48 ` Rafael J. Wysocki
2019-05-09 9:07 ` Rafael J. Wysocki
2019-05-09 9:42 ` Kai-Heng Feng
2019-05-09 9:56 ` Christoph Hellwig
2019-05-09 10:28 ` Kai-Heng Feng
2019-05-09 10:31 ` Christoph Hellwig
2019-05-09 11:59 ` Kai-Heng Feng
2019-05-09 18:57 ` Mario.Limonciello
2019-05-09 19:28 ` Keith Busch
2019-05-09 20:54 ` Rafael J. Wysocki
2019-05-09 21:16 ` Keith Busch
2019-05-09 21:39 ` Rafael J. Wysocki
2019-05-09 21:37 ` Mario.Limonciello
2019-05-09 21:54 ` Keith Busch
2019-05-09 22:19 ` Mario.Limonciello
2019-05-10 6:05 ` Kai-Heng Feng
2019-05-10 8:23 ` Rafael J. Wysocki
2019-05-10 13:52 ` Keith Busch
2019-05-10 15:15 ` Kai Heng Feng
2019-05-10 15:36 ` Keith Busch
2019-05-10 14:02 ` Keith Busch
2019-05-10 15:18 ` Kai Heng Feng
2019-05-10 15:49 ` hch
2019-05-10 5:30 ` Christoph Hellwig
2019-05-10 13:51 ` Keith Busch
2019-05-09 16:20 ` Keith Busch
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=064701C3-2BD4-4D93-891D-B7FBB5040FC4@canonical.com \
--to=kai.heng.feng@canonical.com \
--cc=Mario.Limonciello@dell.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=sagi@grimberg.me \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).