All of lore.kernel.org
 help / color / mirror / Atom feed
From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH v4 0/3] nvme power saving
Date: Fri, 28 Oct 2016 07:29:11 +0200	[thread overview]
Message-ID: <20161028052911.GA8999@lst.de> (raw)
In-Reply-To: <CALCETrVuAfpavqkyfKeqBtcCyZuThNxvOorcvmEzwTxyDrzEpg@mail.gmail.com>

On Thu, Oct 27, 2016@05:06:16PM -0700, Andy Lutomirski wrote:
> It looks like there is at least one NVMe disk in existence (a
> different Samsung device) that sporadically dies when APST is on.
> This device appears to also sporadically die when APST is off, but it
> lasts considerably longer before dying with APST off.

Judy, can you help Andy to find someone in Samsung to report this
to?

> So here's what I'm tempted to do:
> 
>  - For devices that report NVMe version 1.2 support, APST is on by
> default.  I hope this is safe.

It should be safe.  That being said NVMe is being driven more and more
into consumer markets so eventually we will find some device we need
to work around inevitably, but that's life.

>  - For devices that don't report NVMe 1.2 or higher but do report
> APSTA (which implies NVMe 1.1), then we can have a blacklist or a
> whitelist.  A blacklist is nicer, but a whitelist is safer.

We just had a discussion about advertising features before claiming
conformance where they appear in in the NVMe technical working group.
The general concensus was that it should be safe.  I'm thus tempted
to start out with the blacklist.

>  - A sysfs and/or module control allows overriding this.
> 
>  - Implement dev_pm_qos latency control.  The chosen latency (if APST
> is enabled) will be the lesser of the dev_pm_qos setting and a module
> parameter.
> 
> How does that sound?

Great!

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: J Freyensee <james_p_freyensee@linux.intel.com>,
	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>,
	Judy Brock-SSI <judy.brock@ssi.samsung.com>
Subject: Re: [PATCH v4 0/3] nvme power saving
Date: Fri, 28 Oct 2016 07:29:11 +0200	[thread overview]
Message-ID: <20161028052911.GA8999@lst.de> (raw)
In-Reply-To: <CALCETrVuAfpavqkyfKeqBtcCyZuThNxvOorcvmEzwTxyDrzEpg@mail.gmail.com>

On Thu, Oct 27, 2016 at 05:06:16PM -0700, Andy Lutomirski wrote:
> It looks like there is at least one NVMe disk in existence (a
> different Samsung device) that sporadically dies when APST is on.
> This device appears to also sporadically die when APST is off, but it
> lasts considerably longer before dying with APST off.

Judy, can you help Andy to find someone in Samsung to report this
to?

> So here's what I'm tempted to do:
> 
>  - For devices that report NVMe version 1.2 support, APST is on by
> default.  I hope this is safe.

It should be safe.  That being said NVMe is being driven more and more
into consumer markets so eventually we will find some device we need
to work around inevitably, but that's life.

>  - For devices that don't report NVMe 1.2 or higher but do report
> APSTA (which implies NVMe 1.1), then we can have a blacklist or a
> whitelist.  A blacklist is nicer, but a whitelist is safer.

We just had a discussion about advertising features before claiming
conformance where they appear in in the NVMe technical working group.
The general concensus was that it should be safe.  I'm thus tempted
to start out with the blacklist.

>  - A sysfs and/or module control allows overriding this.
> 
>  - Implement dev_pm_qos latency control.  The chosen latency (if APST
> is enabled) will be the lesser of the dev_pm_qos setting and a module
> parameter.
> 
> How does that sound?

Great!

  reply	other threads:[~2016-10-28  5:29 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16 18:16 [PATCH v4 0/3] nvme power saving Andy Lutomirski
2016-09-16 18:16 ` Andy Lutomirski
2016-09-16 18:16 ` [PATCH v4 1/3] nvme/scsi: Remove power management support Andy Lutomirski
2016-09-16 18:16   ` Andy Lutomirski
2016-09-16 23:37   ` J Freyensee
2016-09-16 23:37     ` J Freyensee
2016-09-16 18:16 ` [PATCH v4 2/3] nvme: Pass pointers, not dma addresses, to nvme_get/set_features() Andy Lutomirski
2016-09-16 18:16   ` Andy Lutomirski
2016-09-16 18:16 ` [PATCH v4 3/3] nvme: Enable autonomous power state transitions Andy Lutomirski
2016-09-16 18:16   ` Andy Lutomirski
2016-09-17  0:49 ` [PATCH v4 0/3] nvme power saving J Freyensee
2016-09-17  0:49   ` J Freyensee
2016-09-22  0:11 ` Andy Lutomirski
2016-09-22  0:11   ` Andy Lutomirski
2016-09-22 13:21   ` Christoph Hellwig
2016-09-22 13:21     ` Christoph Hellwig
2016-09-22 14:23 ` Jens Axboe
2016-09-22 14:23   ` Jens Axboe
2016-09-22 20:11   ` Andy Lutomirski
2016-09-22 20:11     ` Andy Lutomirski
2016-09-22 20:43     ` Jens Axboe
2016-09-22 20:43       ` Jens Axboe
2016-09-22 21:33       ` J Freyensee
2016-09-22 21:33         ` J Freyensee
2016-09-22 22:15         ` Andy Lutomirski
2016-09-22 22:15           ` Andy Lutomirski
2016-10-28  0:06           ` Andy Lutomirski
2016-10-28  0:06             ` Andy Lutomirski
2016-10-28  5:29             ` Christoph Hellwig [this message]
2016-10-28  5:29               ` Christoph Hellwig
2016-09-22 22:16         ` Keith Busch
2016-09-22 22:16           ` Keith Busch
2016-09-22 22:07           ` Jens Axboe
2016-09-22 22:07             ` Jens Axboe
2016-09-23 23:42 ` Christoph Hellwig
2016-09-23 23:42   ` Christoph Hellwig
2016-09-24 16:55   ` Jens Axboe
2016-09-24 16:55     ` Jens Axboe

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=20161028052911.GA8999@lst.de \
    --to=hch@lst.de \
    /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.