From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755663AbdELOev (ORCPT ); Fri, 12 May 2017 10:34:51 -0400 Received: from esa1.dell-outbound.iphmx.com ([68.232.153.90]:10508 "EHLO esa1.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755231AbdELOet (ORCPT ); Fri, 12 May 2017 10:34:49 -0400 From: DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version: Return-Path; b=FS5IpC1xLqId3bn2pHKVjTtAez1pdRRRz1Hp3plONWyOodWLMucjzcJ1 lcqfr5guIjOtS4NfWezGjrxRo6ynCLwIwq5mc8gRC0NzJvUoblUnTsyhg GnHoLCTYE6rYBjcZRcTFYYY6HwiJlC2QVDiIBqQGJOFOen2cD8YKm/E2N k=; X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.38,330,1491282000"; d="scan'208";a="18428602" To: CC: , , , , , , Subject: Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe Thread-Topic: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe Thread-Index: AQHSytUdBkAUc+SsG06Yu2RhBlD+VqHwuTVCgABWWQD//7MXDg== Date: Fri, 12 May 2017 14:34:45 +0000 Message-ID: <1494599685838.3433@Dell.com> References: <1494597516613.95190@Dell.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.242.75] Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v4CEYxTd007900 >Yes, mostly. I've written the patch, but I was planning to target it >at 4.12 or 4.13 but not -stable. It's mostly just a cleanup and has >no real power saving benefit since the RSTe timeouts are so absurdly >conservative that I doubt PS4 will happen in practical usage. OK. >Perhaps >in suspend-to-idle? (For suspend-to-idle, I suspect we should really >be using D3 instead. Do we already do that?) Well I think this will depend upon what the SSD "will" support. There isn't good documentation for how Linux "should" handle suspend-to-idle with disks yet, so the best you can follow is what Microsoft publicly mentions for Modern Standby. [1] "Akin to AHCI PCIe SSDs, NVMe SSDs need to provide the host with a non-operational power state that is comparable to DEVSLP (<5mW draw, <100ms exit latency) in order to allow the host to perform appropriate transitions into Modern Standby. Should the NVMe SSD not expose such a non-operational power state, autonomous power state transitions (APST) is the only other option to enter Modern Standby successfully. Note that in the absence of DEVSLP or a comparable NVMe non-operational power state, the host can make no guarantees on the device’s power draw. In this case, if you observe non-optimal power consumption by the device/system, you will have to work with your device vendor to determine the cause." Something important to consider though is that Microsoft keeps more of the OS actually running during Modern Standby but has deep control of what applications and kernel threads are allowed to do. For Linux I think that D3 is most likely going to provide the best power for these disks. [1] https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/device-experiences/part-selection#ssd-storage