Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 19, 2017 at 11:24:39AM -0700, Andy Lutomirski wrote: > On Fri, May 19, 2017 at 7:18 AM, Keith Busch wrote: > > On Thu, May 18, 2017 at 11:35:05PM -0700, Christoph Hellwig wrote: > >> On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: > >> > a)

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 19, 2017 at 11:24:39AM -0700, Andy Lutomirski wrote: > On Fri, May 19, 2017 at 7:18 AM, Keith Busch wrote: > > On Thu, May 18, 2017 at 11:35:05PM -0700, Christoph Hellwig wrote: > >> On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: > >> > a) Leave the Dell quirk in

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 19, 2017 at 7:18 AM, Keith Busch wrote: > On Thu, May 18, 2017 at 11:35:05PM -0700, Christoph Hellwig wrote: >> On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: >> > a) Leave the Dell quirk in place until someone from Dell or Samsung >> > figures

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 19, 2017 at 7:18 AM, Keith Busch wrote: > On Thu, May 18, 2017 at 11:35:05PM -0700, Christoph Hellwig wrote: >> On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: >> > a) Leave the Dell quirk in place until someone from Dell or Samsung >> > figures out what's actually

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 19, 2017 at 10:18:34AM -0400, Keith Busch wrote: > + > + if (ns->ctrl->quirks & NVME_QUIRK_PAGE_ALIGN) > + blk_queue_logical_block_size(ns->queue, ns->ctrl->page_size); > + else > + blk_queue_logical_block_size(ns->queue, bs); Ugg. That will invalidate

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 19, 2017 at 10:18:34AM -0400, Keith Busch wrote: > + > + if (ns->ctrl->quirks & NVME_QUIRK_PAGE_ALIGN) > + blk_queue_logical_block_size(ns->queue, ns->ctrl->page_size); > + else > + blk_queue_logical_block_size(ns->queue, bs); Ugg. That will invalidate

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 18, 2017 at 11:35:05PM -0700, Christoph Hellwig wrote: > On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: > > a) Leave the Dell quirk in place until someone from Dell or Samsung > > figures out what's actually going on. Add a blanket quirk turning off > > the deepest

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 18, 2017 at 11:35:05PM -0700, Christoph Hellwig wrote: > On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: > > a) Leave the Dell quirk in place until someone from Dell or Samsung > > figures out what's actually going on. Add a blanket quirk turning off > > the deepest

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: > a) Leave the Dell quirk in place until someone from Dell or Samsung > figures out what's actually going on. Add a blanket quirk turning off > the deepest sleep state on all Intel devices [1] at least until > someone from Intel

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote: > a) Leave the Dell quirk in place until someone from Dell or Samsung > figures out what's actually going on. Add a blanket quirk turning off > the deepest sleep state on all Intel devices [1] at least until > someone from Intel

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 18, 2017 at 6:32 PM, wrote: >> I pondered this a bit, and I want to NAK my own patch. This patch >> stinks -- there's mounting evidence that what it really does is to >> make any problems show up more rarely. If a system is broken, I want >> it to be

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 18, 2017 at 6:32 PM, wrote: >> I pondered this a bit, and I want to NAK my own patch. This patch >> stinks -- there's mounting evidence that what it really does is to >> make any problems show up more rarely. If a system is broken, I want >> it to be obviously broken. >> >> Here

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

> I pondered this a bit, and I want to NAK my own patch. This patch > stinks -- there's mounting evidence that what it really does is to > make any problems show up more rarely. If a system is broken, I want > it to be obviously broken. > > Here are two options to move forward: > > a) Leave the

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

> I pondered this a bit, and I want to NAK my own patch. This patch > stinks -- there's mounting evidence that what it really does is to > make any problems show up more rarely. If a system is broken, I want > it to be obviously broken. > > Here are two options to move forward: > > a) Leave the

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

com>; Limonciello, Mario <mario_limoncie...@dell.com> >> Subject: Re: [PATCH] nvme: Change our APST table to be no more aggressive >> than >> Intel RSTe >> >> On Thu, May 11, 2017 at 9:06 PM, Andy Lutomirski <l...@kernel.org> wrote: >> > It

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

x-nvme ; >> Christoph Hellwig ; Sagi Grimberg ; Keith >> Busch >> ; Limonciello, Mario >> Subject: Re: [PATCH] nvme: Change our APST table to be no more aggressive >> than >> Intel RSTe >> >> On Thu, May 11, 2017 at 9:06 PM, Andy Lutomirski wrote: &

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 11, 2017 at 9:06 PM, Andy Lutomirski wrote: > It seems like RSTe is much more conservative with transition timing > that we are. According to Mario, RSTe programs APST to transition from > active states to the first idle state after 60ms and, thereafter, to > 1000 *

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 11, 2017 at 9:06 PM, Andy Lutomirski wrote: > It seems like RSTe is much more conservative with transition timing > that we are. According to Mario, RSTe programs APST to transition from > active states to the first idle state after 60ms and, thereafter, to > 1000 * the exit latency

RE: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

nonical.com>; linux-nvme <linux-n...@lists.infradead.org>; > Christoph Hellwig <h...@lst.de>; Sagi Grimberg <s...@grimberg.me>; Keith Busch > <keith.bu...@intel.com>; Limonciello, Mario <mario_limoncie...@dell.com> > Subject: Re: [PATCH] nvme: Change our APST table t

RE: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

gt; ; Limonciello, Mario > Subject: Re: [PATCH] nvme: Change our APST table to be no more aggressive than > Intel RSTe > > On Thu, May 11, 2017 at 9:06 PM, Andy Lutomirski wrote: > > It seems like RSTe is much more conservative with transition timing > > that we are. According

RE: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

> On Fri, May 12, 2017 at 7:34 AM, wrote: > >>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 >

RE: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

> On Fri, May 12, 2017 at 7:34 AM, wrote: > >>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

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 11, 2017 at 9:06 PM, Andy Lutomirski wrote: > It seems like RSTe is much more conservative with transition timing > that we are. According to Mario, RSTe programs APST to transition from > active states to the first idle state after 60ms and, thereafter, to > 1000 *

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Thu, May 11, 2017 at 9:06 PM, Andy Lutomirski wrote: > It seems like RSTe is much more conservative with transition timing > that we are. According to Mario, RSTe programs APST to transition from > active states to the first idle state after 60ms and, thereafter, to > 1000 * the exit latency

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 12, 2017 at 7:34 AM, wrote: >>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

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 12, 2017 at 7:34 AM, wrote: >>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

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

>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

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

>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

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 12, 2017 at 6:58 AM, wrote: >> Some testing reports suggest that this will fix the issues we've >> seen on Dell laptops. > > It think it also makes sense to revert the quirk that was created based upon > the previous aggressiveness of re-entry to PS4 on

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

On Fri, May 12, 2017 at 6:58 AM, wrote: >> Some testing reports suggest that this will fix the issues we've >> seen on Dell laptops. > > It think it also makes sense to revert the quirk that was created based upon > the previous aggressiveness of re-entry to PS4 on those machines. Are you >

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

> Some testing reports suggest that this will fix the issues we've > seen on Dell laptops. It think it also makes sense to revert the quirk that was created based upon the previous aggressiveness of re-entry to PS4 on those machines. Are you expecting to split that up into a second patch also

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

> Some testing reports suggest that this will fix the issues we've > seen on Dell laptops. It think it also makes sense to revert the quirk that was created based upon the previous aggressiveness of re-entry to PS4 on those machines. Are you expecting to split that up into a second patch also

[PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

It seems like RSTe is much more conservative with transition timing that we are. According to Mario, RSTe programs APST to transition from active states to the first idle state after 60ms and, thereafter, to 1000 * the exit latency of the target state. This is IMO a terrible policy. On my

[PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

It seems like RSTe is much more conservative with transition timing that we are. According to Mario, RSTe programs APST to transition from active states to the first idle state after 60ms and, thereafter, to 1000 * the exit latency of the target state. This is IMO a terrible policy. On my