From mboxrd@z Thu Jan 1 00:00:00 1970 From: kbusch@kernel.org (Keith Busch) Date: Mon, 13 May 2019 08:55:24 -0600 Subject: [PATCH] nvme/pci: Use host managed power state for suspend In-Reply-To: References: <20190510212937.11661-1-keith.busch@intel.com> <0080aaff18e5445dabca509d4113eca8@AUSX13MPC105.AMER.DELL.COM> <955722d8fc16425dbba0698c4806f8fd@AUSX13MPC105.AMER.DELL.COM> <20190513143741.GA25500@lst.de> Message-ID: <20190513145522.GA15421@localhost.localdomain> On Mon, May 13, 2019@02:43:43PM +0000, Mario.Limonciello@dell.com wrote: > > Well, it sounds like your partners device does not work properly in this > > case. There is nothing in the NVMe spec that says queues should be > > torn down for deep power states, and that whole idea seems rather > > counter productive to low-latency suspend/resume cycles. > > Well I've got a thought, quoting the NVME spec: > "After a successful completion of a Set Features command for this feature, the controller shall be in the > Power State specified. If enabled, autonomous power state transitions continue to occur from the new state." > > If APST is enabled on this disk, what is to stop an autonomous reverse > transition from queue activity on the way down? Regardless of whether APST is enabled or not, the controller may autonomously transition out of a host requested low power state in response to host activity. Exiting a low power state should mean some other task is actively using the device, and if that's the case, why are you trying to enter a low power state in the first place? Alternatively, if host activity really is idle, then why is the device autonomously leaving the requested state? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Busch Subject: Re: [PATCH] nvme/pci: Use host managed power state for suspend Date: Mon, 13 May 2019 08:55:24 -0600 Message-ID: <20190513145522.GA15421@localhost.localdomain> References: <20190510212937.11661-1-keith.busch@intel.com> <0080aaff18e5445dabca509d4113eca8@AUSX13MPC105.AMER.DELL.COM> <955722d8fc16425dbba0698c4806f8fd@AUSX13MPC105.AMER.DELL.COM> <20190513143741.GA25500@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Mario.Limonciello@dell.com Cc: hch@lst.de, keith.busch@intel.com, sagi@grimberg.me, linux-nvme@lists.infradead.org, rafael@kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, kai.heng.feng@canonical.com List-Id: linux-pm@vger.kernel.org On Mon, May 13, 2019 at 02:43:43PM +0000, Mario.Limonciello@dell.com wrote: > > Well, it sounds like your partners device does not work properly in this > > case. There is nothing in the NVMe spec that says queues should be > > torn down for deep power states, and that whole idea seems rather > > counter productive to low-latency suspend/resume cycles. > > Well I've got a thought, quoting the NVME spec: > "After a successful completion of a Set Features command for this feature, the controller shall be in the > Power State specified. If enabled, autonomous power state transitions continue to occur from the new state." > > If APST is enabled on this disk, what is to stop an autonomous reverse > transition from queue activity on the way down? Regardless of whether APST is enabled or not, the controller may autonomously transition out of a host requested low power state in response to host activity. Exiting a low power state should mean some other task is actively using the device, and if that's the case, why are you trying to enter a low power state in the first place? Alternatively, if host activity really is idle, then why is the device autonomously leaving the requested state?