NVMe APST high latency power states being skipped

[Kai-Heng Feng]

On Tue, Jun 6, 2017 at 11:57 PM, Andy Lutomirski <luto at kernel.org> wrote:
> On Tue, Jun 6, 2017 at 2:54 AM, Christoph Hellwig <hch at infradead.org> wrote:
>> On Fri, Jun 02, 2017 at 12:13:37AM -0700, Christoph Hellwig wrote:
>>> > Maybe add an extra knob which can directly control deepest allow power
>>> > state? Userspace tools can control deepest power state through this
>>> > knob.
>>>
>>> I'd prefer that things work out of the box.  I'd be tempted to just
>>> bump up the latency requirement to cover the device, but if Andy
>>> doesn't like that in general we could add a quirk for this device
>>> to at least allow it to use deep power states.
>>
>> Kai, can you send the patch to bump default_ps_max_latency_us to
>> reasonably high value that all the devices you are testing are
>> able to use PS3/4?
>
> I'm starting to think we should ignore enlat and only consider exlat
> when we interpret the requested max latency.  If I find some time,
> I'll try to write a little benchmark to see how drives actually
> behave.

Suppose a NVMe with 5ms enlat and 5ms exlat, the Idle Time Prior to
Transition is 500ms.
I'd say that most of the time, the no I/O activities period will also
spans over the entlat's 5ms time window, hence the only impactful
latency here is limited to exlat.
The chance to occur 10ms latency (device transits back to op state
right after it enters non-op state) should be low.

So I think you are right, only considering exlat will be more close to
real world scenario.

>
> Given that we've seen enlat as high as 1s, I don't think we want to
> start setting the default latency over 1s.

The highest PS4 exlat on NVMes at my hand is 100ms. Newer NVMe should
have better latency.

I'll send a patch for this, thanks for the info.