From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH v3 3/3] nvme: Enable autonomous power state transitions
Date: Fri, 16 Sep 2016 11:38:39 -0400 [thread overview]
Message-ID: <20160916153839.GA32151@localhost.localdomain> (raw)
In-Reply-To: <6d237c11f22f03365789682484755b84eb6b4493.1474002926.git.luto@kernel.org>
On Thu, Sep 15, 2016@10:24:21PM -0700, Andy Lutomirski wrote:
> NVMe devices can advertise multiple power states. These states can
> be either "operational" (the device is fully functional but possibly
> slow) or "non-operational" (the device is asleep until woken up).
> Some devices can automatically enter a non-operational state when
> idle for a specified amount of time and then automatically wake back
> up when needed.
>
> The hardware configuration is a table. For each state, an entry in
> the table indicates the next deeper non-operational state, if any,
> to autonomously transition to and the idle time required before
> transitioning.
>
> This patch teaches the driver to program APST so that each
> successive non-operational state will be entered after an idle time
> equal to 100% of the total latency (entry plus exit) associated with
> that state. A sysfs attribute 'ps_max_latency_us' gives the maximum
> acceptable latency in ns; non-operational states with total latency
> greater than this value will not be used. As a special case,
> ps_max_latency_us=0 will disable APST entirely. On hardware without
> APST support, ps_max_latency_us will not be exposed in sysfs.
>
> The ps_max_latency_us parameter for newly-probed devices is set by
> the module parameter nvme_core.default_ps_max_latency_us.
>
> In theory, the device can expose "default" APST table, but this
> doesn't seem to function correctly on my device (Samsung 950), nor
> does it seem particularly useful. There is also an optional
> mechanism by which a configuration can be "saved" so it will be
> automatically loaded on reset. This can be configured from
> userspace, but it doesn't seem useful to support in the driver.
>
> On my laptop, enabling APST seems to save nearly 1W.
>
> The hardware tables can be decoded in userspace with nvme-cli.
> 'nvme id-ctrl /dev/nvmeN' will show the power state table and
> 'nvme get-feature -f 0x0c -H /dev/nvme0' will show the current APST
> configuration.
>
> I called the parameters ps_max_latency_us instead of
> apst_max_latency_us because we might support other power saving
> modes (e.g. non-automonous power state transitions or even runtime
> D3) and the same parameter could control the maximum allowable
> latency for these states as well.
>
> Signed-off-by: Andy Lutomirski <luto at kernel.org>
Thanks, looks good to me.
Reviewed-by: Keith Busch <keith.busch at intel.com>
prev parent reply other threads:[~2016-09-16 15:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-16 5:24 [PATCH v3 0/3] nvme power saving Andy Lutomirski
2016-09-16 5:24 ` [PATCH v3 1/3] nvme/scsi: Remove power management support Andy Lutomirski
2016-09-16 8:33 ` Christoph Hellwig
2016-09-16 14:33 ` Keith Busch
2016-09-16 14:25 ` Christoph Hellwig
2016-09-19 7:59 ` Johannes Thumshirn
2016-09-16 23:33 ` J Freyensee
2016-09-16 5:24 ` [PATCH v3 2/3] nvme: Pass pointers, not dma addresses, to nvme_get/set_features() Andy Lutomirski
2016-09-16 8:41 ` Christoph Hellwig
2016-09-16 15:13 ` Andy Lutomirski
2016-09-16 15:34 ` Jens Axboe
2016-09-16 5:24 ` [PATCH v3 3/3] nvme: Enable autonomous power state transitions Andy Lutomirski
2016-09-16 8:42 ` Christoph Hellwig
2016-09-16 15:14 ` Andy Lutomirski
2016-09-16 16:51 ` Christoph Hellwig
2016-09-16 15:38 ` Keith Busch [this message]
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=20160916153839.GA32151@localhost.localdomain \
--to=keith.busch@intel.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: 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).