All of lore.kernel.org
 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.

WARNING: multiple messages have this Message-ID (diff)
From: J Freyensee <james_p_freyensee@linux.intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Jens Axboe <axboe@fb.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-nvme@lists.infradead.org,
	Keith Busch <keith.busch@intel.com>,
	Andy Lutomirski <luto@kernel.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: [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 at 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 at 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: 14+ 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 ` Andy Lutomirski
2016-08-30 21:59 ` [PATCH v2 1/3] nvme/scsi: Remove power management support Andy Lutomirski
2016-08-30 21:59   ` 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   ` Andy Lutomirski
2016-08-30 21:59 ` [PATCH v2 3/3] nvme: Enable autonomous power state transitions Andy Lutomirski
2016-08-30 21:59   ` Andy Lutomirski
2016-09-02 21:15   ` J Freyensee
2016-09-02 21:15     ` J Freyensee
2016-09-02 21:43     ` Andy Lutomirski
2016-09-02 21:43       ` Andy Lutomirski
2016-09-02 22:23       ` J Freyensee [this message]
2016-09-02 22:23         ` J Freyensee

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 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.