From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935618AbcIPP1u (ORCPT ); Fri, 16 Sep 2016 11:27:50 -0400 Received: from mga01.intel.com ([192.55.52.88]:21802 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758589AbcIPP1i (ORCPT ); Fri, 16 Sep 2016 11:27:38 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,345,1470726000"; d="scan'208";a="169499500" Date: Fri, 16 Sep 2016 11:38:39 -0400 From: Keith Busch To: Andy Lutomirski Cc: Jens Axboe , linux-nvme@lists.infradead.org, Christoph Hellwig , linux-kernel@vger.kernel.org, J Freyensee Subject: Re: [PATCH v3 3/3] nvme: Enable autonomous power state transitions Message-ID: <20160916153839.GA32151@localhost.localdomain> References: <6d237c11f22f03365789682484755b84eb6b4493.1474002926.git.luto@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6d237c11f22f03365789682484755b84eb6b4493.1474002926.git.luto@kernel.org> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 15, 2016 at 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 Thanks, looks good to me. Reviewed-by: Keith Busch