linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: james_p_freyensee@linux.intel.com (J Freyensee)
Subject: [PATCH v2 3/3] nvme: Enable autonomous power state transitions
Date: Fri, 02 Sep 2016 15:23:05 -0700	[thread overview]
Message-ID: <1472854985.2946.45.camel@linux.intel.com> (raw)
In-Reply-To: <CALCETrVoMEzmjfj--e09F8Ss8Dp9CFAmuuBhFoHOSNDoxHu6aQ@mail.gmail.com>

On Fri, 2016-09-02@14:43 -0700, Andy Lutomirski wrote:
> On Fri, Sep 2, 2016 at 2:15 PM, J Freyensee
> <james_p_freyensee@linux.intel.com> wrote:
> > 
> > On Tue, 2016-08-30@14:59 -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 'apst_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, apst_max_latency_us=0 will disable APST entirely.
> > 
> > May I ask a dumb question?
> > 
> > How does this work with multiple NVMe devices plugged into a
> > system???I
> > would have thought we'd want one apst_max_latency_us entry per NVMe
> > controller for individual control of each device???I have two
> > Fultondale-class devices plugged into a system I tried these
> > patches on
> > (the 4.8-rc4 kernel) and I'm not sure how the single
> > /sys/module/nvme_core/parameters/apst_max_latency_us would work per
> > my
> > 2 devices (and the value is using the default 25000).
> > 
> 
> Ah, I faked you out :(
> 
> The module parameter (nvme_core/parameters/apst_max_latency_us) just
> sets the default for newly probed devices.??The actual setting is in
> /sys/devices/whatever (symlinked from /sys/block/nvme0n1/devices, for
> example).??Perhaps I should name the former
> default_apst_max_latency_us.

It would certainly be more describable to understand what the entry is
for, but then the name is also getting longer.

Just "default_apst_latency_us"? Or maybe it's probably fine as-is.

      reply	other threads:[~2016-09-02 22:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-30 21:59 [PATCH v2 0/3] nvme power saving Andy Lutomirski
2016-08-30 21:59 ` [PATCH v2 1/3] nvme/scsi: Remove power management support Andy Lutomirski
2016-08-30 21:59 ` [PATCH v2 2/3] nvme: Pass pointers, not dma addresses, to nvme_get/set_features() Andy Lutomirski
2016-08-30 21:59 ` [PATCH v2 3/3] nvme: Enable autonomous power state transitions Andy Lutomirski
2016-09-02 21:15   ` J Freyensee
2016-09-02 21:43     ` Andy Lutomirski
2016-09-02 22:23       ` J Freyensee [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=1472854985.2946.45.camel@linux.intel.com \
    --to=james_p_freyensee@linux.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).