[PATCH] nvme: lower default APST max latency to 25ms

[PATCH] nvme: lower default APST max latency to 25ms

[Ferran Duarri]

That one bound decides how deep a device may sleep. On a device that
advertises a non-operational state an order of magnitude slower than the
next one up, the 100ms default silently selects the slow one, and the
first read after an idle period pays that wake in full. It shows up as a
stall rather than as reduced throughput, being a one-shot cost on a cold
access rather than a steady-state penalty. The workload that prompted
this is staging large model weights from NVMe, where a cold mmap fault
on a multi-gigabyte checkpoint is exactly that access.

Measured on a Samsung SSD 990 EVO Plus 4TB (fw 2B2QKXG7), which
advertises two non-operational states:

  ps 3   exit  4.6ms   0.0800W
  ps 4   exit 43.0ms   0.0070W

At 100000 the APST table targets ps 4; at 25000 it targets ps 3. Cold
4KiB O_DIRECT reads after an idle period, 60 trials per setting, the two
settings interleaved trial by trial:

                     p50      p90      p99      max
  100000 (ps 4)     3.3ms   33.0ms   33.5ms   33.5ms
  25000  (ps 3)     3.2ms    3.6ms    3.7ms    4.2ms
  warm, no idle     0.2ms    0.3ms    1.7ms    3.6ms

Observed worst case falls from 33.5ms to 4.2ms. Both states measured 78%
of their advertised exit latency, which is the cross-check that the two
figures measure the same thing at two magnitudes.

The p50 at 100000 needs reading carefully: roughly five trials in six did
not finish descending to ps 4 inside the idle window and were sampled at
ps 3 depth, which pulls that row's median down to the 25000 row's value.
The ps 4 column therefore rests on the remaining sixth, where it was
tightly reproducible, 32.9ms to 33.5ms. That effect can only understate
the cost of the current default, never overstate it.

25ms is not derived from this device. It is a bound on latency an
interactive reader notices; any value between 4.6ms and 43ms behaves
identically here. The device is an existence proof that the 100ms
default admits a state far slower than the next available one, not the
source of the constant. On a device whose deepest non-operational state
exits well under 25ms this changes nothing, which is correct for a bound.

The cost is idle power. Excluding ps 4 leaves ps 3 as the deepest state
the device reaches autonomously, 0.0800W rather than 0.0070W, so roughly
73mW more on an idle drive.

This changes only the compiled-in default. default_ps_max_latency_us is
consumed once per controller in nvme_add_ctrl(), so it applies from the
kernel command line as nvme_core.default_ps_max_latency_us=. A running
controller instead follows its per-device PM QOS value
(pm_qos_latency_tolerance_us), which is how the two settings above were
compared without a reboot. Any system preferring deeper idle states can
restore the old behaviour without a rebuild.

Assisted-by: Claude:claude-opus-5 checkpatch patch-audit
Signed-off-by: Ferran Duarri <ferran.duarri@me.com>
---
 drivers/nvme/host/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index c3032d6ad6b1..e3038b880e8b 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -66,7 +66,7 @@ static u8 nvme_max_retries = 5;
 module_param_named(max_retries, nvme_max_retries, byte, 0644);
 MODULE_PARM_DESC(max_retries, "max number of retries a command may have");
 
-static unsigned long default_ps_max_latency_us = 100000;
+static unsigned long default_ps_max_latency_us = 25000;
 module_param(default_ps_max_latency_us, ulong, 0644);
 MODULE_PARM_DESC(default_ps_max_latency_us,
 		 "max power saving latency for new devices; use PM QOS to change per device");

[PATCH] nvme: lower default APST max latency to 25ms

[Ferran Duarri]

That one bound decides how deep a device may sleep. On a device that
advertises a non-operational state an order of magnitude slower than the
next one up, the 100ms default silently selects the slow one, and the
first read after an idle period pays that wake in full. It shows up as a
stall rather than as reduced throughput, being a one-shot cost on a cold
access rather than a steady-state penalty. The workload that prompted
this is staging large model weights from NVMe, where a cold mmap fault
on a multi-gigabyte checkpoint is exactly that access.

Measured on a Samsung SSD 990 EVO Plus 4TB (fw 2B2QKXG7), which
advertises two non-operational states:

  ps 3   exit  4.6ms   0.0800W
  ps 4   exit 43.0ms   0.0070W

At 100000 the APST table targets ps 4; at 25000 it targets ps 3. Cold
4KiB O_DIRECT reads after an idle period, 60 trials per setting, the two
settings interleaved trial by trial:

                     p50      p90      p99      max
  100000 (ps 4)     3.3ms   33.0ms   33.5ms   33.5ms
  25000  (ps 3)     3.2ms    3.6ms    3.7ms    4.2ms
  warm, no idle     0.2ms    0.3ms    1.7ms    3.6ms

Observed worst case falls from 33.5ms to 4.2ms. Both states measured 78%
of their advertised exit latency, which is the cross-check that the two
figures measure the same thing at two magnitudes.

The p50 at 100000 needs reading carefully: roughly five trials in six did
not finish descending to ps 4 inside the idle window and were sampled at
ps 3 depth, which pulls that row's median down to the 25000 row's value.
The ps 4 column therefore rests on the remaining sixth, where it was
tightly reproducible, 32.9ms to 33.5ms. That effect can only understate
the cost of the current default, never overstate it.

25ms is not derived from this device. It is a bound on latency an
interactive reader notices; any value between 4.6ms and 43ms behaves
identically here. The device is an existence proof that the 100ms
default admits a state far slower than the next available one, not the
source of the constant. On a device whose deepest non-operational state
exits well under 25ms this changes nothing, which is correct for a bound.

The cost is idle power. Excluding ps 4 leaves ps 3 as the deepest state
the device reaches autonomously, 0.0800W rather than 0.0070W, so roughly
73mW more on an idle drive.

This changes only the compiled-in default. default_ps_max_latency_us is
consumed once per controller in nvme_add_ctrl(), so it applies from the
kernel command line as nvme_core.default_ps_max_latency_us=. A running
controller instead follows its per-device PM QOS value
(pm_qos_latency_tolerance_us), which is how the two settings above were
compared without a reboot. Any system preferring deeper idle states can
restore the old behaviour without a rebuild.

Signed-off-by: Ferran Duarri <ferran.duarri@me.com>
---
 drivers/nvme/host/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index c3032d6ad6b1..e3038b880e8b 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -66,7 +66,7 @@ static u8 nvme_max_retries = 5;
 module_param_named(max_retries, nvme_max_retries, byte, 0644);
 MODULE_PARM_DESC(max_retries, "max number of retries a command may have");
 
-static unsigned long default_ps_max_latency_us = 100000;
+static unsigned long default_ps_max_latency_us = 25000;
 module_param(default_ps_max_latency_us, ulong, 0644);
 MODULE_PARM_DESC(default_ps_max_latency_us,
 		 "max power saving latency for new devices; use PM QOS to change per device");

[PATCH] nvme: lower default APST max latency to 25ms

[Ferran Duarri]

That one bound decides how deep a device may sleep. On a device that
advertises a non-operational state an order of magnitude slower than the
next one up, the 100ms default silently selects the slow one, and the
first read after an idle period pays that wake in full. It shows up as a
stall rather than as reduced throughput, being a one-shot cost on a cold
access rather than a steady-state penalty. The workload that prompted
this is staging large model weights from NVMe, where a cold mmap fault
on a multi-gigabyte checkpoint is exactly that access.

Measured on a Samsung SSD 990 EVO Plus 4TB (fw 2B2QKXG7), which
advertises two non-operational states:

  ps 3   exit  4.6ms   0.0800W
  ps 4   exit 43.0ms   0.0070W

At 100000 the APST table targets ps 4; at 25000 it targets ps 3. Cold
4KiB O_DIRECT reads after an idle period, 60 trials per setting, the two
settings interleaved trial by trial:

                     p50      p90      p99      max
  100000 (ps 4)     3.3ms   33.0ms   33.5ms   33.5ms
  25000  (ps 3)     3.2ms    3.6ms    3.7ms    4.2ms
  warm, no idle     0.2ms    0.3ms    1.7ms    3.6ms

Observed worst case falls from 33.5ms to 4.2ms. Both states measured 78%
of their advertised exit latency, which is the cross-check that the two
figures measure the same thing at two magnitudes.

The p50 at 100000 needs reading carefully: roughly five trials in six did
not finish descending to ps 4 inside the idle window and were sampled at
ps 3 depth, which pulls that row's median down to the 25000 row's value.
The ps 4 column therefore rests on the remaining sixth, where it was
tightly reproducible, 32.9ms to 33.5ms. That effect can only understate
the cost of the current default, never overstate it.

25ms is not derived from this device. It is a bound on latency an
interactive reader notices; any value between 4.6ms and 43ms behaves
identically here. The device is an existence proof that the 100ms
default admits a state far slower than the next available one, not the
source of the constant. On a device whose deepest non-operational state
exits well under 25ms this changes nothing, which is correct for a bound.

The cost is idle power. Excluding ps 4 leaves ps 3 as the deepest state
the device reaches autonomously, 0.0800W rather than 0.0070W, so roughly
73mW more on an idle drive.

This changes only the compiled-in default. default_ps_max_latency_us is
consumed once per controller in nvme_add_ctrl(), so it applies from the
kernel command line as nvme_core.default_ps_max_latency_us=. A running
controller instead follows its per-device PM QOS value
(pm_qos_latency_tolerance_us), which is how the two settings above were
compared without a reboot. Any system preferring deeper idle states can
restore the old behaviour without a rebuild.

Signed-off-by: Ferran Duarri <ferran.duarri@me.com>
---
 drivers/nvme/host/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index c3032d6ad6b1..e3038b880e8b 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -66,7 +66,7 @@ static u8 nvme_max_retries = 5;
 module_param_named(max_retries, nvme_max_retries, byte, 0644);
 MODULE_PARM_DESC(max_retries, "max number of retries a command may have");
 
-static unsigned long default_ps_max_latency_us = 100000;
+static unsigned long default_ps_max_latency_us = 25000;
 module_param(default_ps_max_latency_us, ulong, 0644);
 MODULE_PARM_DESC(default_ps_max_latency_us,
 		 "max power saving latency for new devices; use PM QOS to change per device");

RE: [PATCH] nvme: lower default APST max latency to 25ms

[Alexey Bogoslavsky]

On Thu, Aug 20, 2026 at 09:54:14PM +0200, Ferran Duarri wrote:
> That one bound decides how deep a device may sleep. On a device that
> advertises a non-operational state an order of magnitude slower than the
> next one up, the 100ms default silently selects the slow one, and the
> first read after an idle period pays that wake in full. It shows up as a
> stall rather than as reduced throughput, being a one-shot cost on a cold
> access rather than a steady-state penalty. The workload that prompted
> this is staging large model weights from NVMe, where a cold mmap fault
> on a multi-gigabyte checkpoint is exactly that access.

> Measured on a Samsung SSD 990 EVO Plus 4TB (fw 2B2QKXG7), which
> advertises two non-operational states:

>  ps 3   exit  4.6ms   0.0800W
>  ps 4   exit 43.0ms   0.0070W

> At 100000 the APST table targets ps 4; at 25000 it targets ps 3. Cold
> 4KiB O_DIRECT reads after an idle period, 60 trials per setting, the two
> settings interleaved trial by trial:

                     p50      p90      p99      max
>  100000 (ps 4)     3.3ms   33.0ms   33.5ms   33.5ms
>  25000  (ps 3)     3.2ms    3.6ms    3.7ms    4.2ms
>  warm, no idle     0.2ms    0.3ms    1.7ms    3.6ms

> Observed worst case falls from 33.5ms to 4.2ms. Both states measured 78%
> of their advertised exit latency, which is the cross-check that the two
> figures measure the same thing at two magnitudes.

> The p50 at 100000 needs reading carefully: roughly five trials in six did
> not finish descending to ps 4 inside the idle window and were sampled at
> ps 3 depth, which pulls that row's median down to the 25000 row's value.
> The ps 4 column therefore rests on the remaining sixth, where it was
> tightly reproducible, 32.9ms to 33.5ms. That effect can only understate
> the cost of the current default, never overstate it.

> 25ms is not derived from this device. It is a bound on latency an
> interactive reader notices; any value between 4.6ms and 43ms behaves
> identically here. The device is an existence proof that the 100ms
> default admits a state far slower than the next available one, not the
> source of the constant. On a device whose deepest non-operational state
> exits well under 25ms this changes nothing, which is correct for a bound.

> The cost is idle power. Excluding ps 4 leaves ps 3 as the deepest state
> the device reaches autonomously, 0.0800W rather than 0.0070W, so roughly
> 73mW more on an idle drive.

As you noted, the advertised latency is not necessarily the real
latency. But you may not have taken into account why the latencies
are advertised the way they are. In client devices, the EXLAT+ENLAT
values are derived from Microsoft guidelines available here:
https://learn.microsoft.com/en-us/windows-hardware/design/
component-guidelines/power-management-for-storage-hardware-devices-nvme
To get to a situation in Windows where PS3 is used most of the time,
the PS4 latency is sometimes advertised as much higher than in reality.
Also, transitional energy can be high and is not measurable using just
the power state values (transitional energy in worst case is PS0 power
for the entire EXLAT, but in reality it's generally lower).

I would recommend Linux keep aligning with the Windows values since
those are the ones client devices optimize for. Selecting 25ms as the
default will ensure that PS4 is never used in devices that are aligned
with Windows, which will cost more power even though it will improve
responsiveness. Some OEMs will find it unacceptable, as was the case
before I introduced the current APST algorithm back in 2021.

I believe that whenever latency is that important in the workload,
users should explicitly disable power management (as one would do on
Windows by switching to performance mode), but this shouldn't be the
default.

> This changes only the compiled-in default. default_ps_max_latency_us is
> consumed once per controller in nvme_add_ctrl(), so it applies from the
> kernel command line as nvme_core.default_ps_max_latency_us=. A running
> controller instead follows its per-device PM QOS value
> (pm_qos_latency_tolerance_us), which is how the two settings above were
> compared without a reboot. Any system preferring deeper idle states can
> restore the old behaviour without a rebuild.

> Signed-off-by: Ferran Duarri <ferran.duarri@me.com>
> ---
>  drivers/nvme/host/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index c3032d6ad6b1..e3038b880e8b 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -66,7 +66,7 @@ static u8 nvme_max_retries = 5;
>  module_param_named(max_retries, nvme_max_retries, byte, 0644);
>  MODULE_PARM_DESC(max_retries, "max number of retries a command may have");

> -static unsigned long default_ps_max_latency_us = 100000;
> +static unsigned long default_ps_max_latency_us = 25000;
>  module_param(default_ps_max_latency_us, ulong, 0644);
> MODULE_PARM_DESC(default_ps_max_latency_us,
>                "max power saving latency for new devices; use PM QOS to change per device");

Re: [PATCH] nvme: lower default APST max latency to 25ms

[Ferran Duarri]

Alexey - thanks, that's a real point I hadn't considered: if EXLAT is
deliberately inflated to keep Windows on ps3, the 100ms default isn't a bug,
it's aligned with what vendors actually tuned for.

The measurement itself I think still holds - it's reading what the drive's
live APST table targets, not just trusting the label, and the wake cost at
ps4 was real regardless of why 43ms is the number on the tin. But that's a
different question from whether Linux should default away from it.

What's the OEM precedent you mentioned - did lowering the bound before break
something specific, or was it more general pushback? Trying to understand if
this needs to stay a boot-time opt-in (which it already is via
default_ps_max_latency_us) rather than ever being a compiled default, on any
hardware.

Also - sorry for the fourth copy of this patch landing in your inbox on the
28th. That was a bookkeeping failure on my end, not a deliberate re-post; it
went out after your reply had already arrived and should not have.

Cheers,
Ferran

RE: [PATCH] nvme: lower default APST max latency to 25ms

[Alexey Bogoslavsky]

> -----Original Message-----
> From: Ferran Duarri <ferran.duarri@me.com> 
> Sent: Monday, August 31, 2026 4:17 PM
> To: Alexey Bogoslavsky <Alexey.Bogoslavsky@sandisk.com>; Keith Busch <kbusch@kernel.org>; Jens Axboe <axboe@kernel.dk>; Christoph Hellwig <hch@lst.de>; Sagi Grimberg <sagi@grimberg.me>
> Cc: Yehuda Hahn <Yehuda.Hahn@sandisk.com>; linux-nvme@lists.infradead.org; linux-kernel@vger.kernel.org; Ferran Duarri <ferran.duarri@me.com>
> Subject: Re: [PATCH] nvme: lower default APST max latency to 25ms

> Alexey - thanks, that's a real point I hadn't considered: if EXLAT is
> deliberately inflated to keep Windows on ps3, the 100ms default isn't a bug,
> it's aligned with what vendors actually tuned for.

> The measurement itself I think still holds - it's reading what the drive's
> live APST table targets, not just trusting the label, and the wake cost at
> ps4 was real regardless of why 43ms is the number on the tin. But that's a
> different question from whether Linux should default away from it.

> What's the OEM precedent you mentioned - did lowering the bound before break
> something specific, or was it more general pushback? Trying to understand if
> this needs to stay a boot-time opt-in (which it already is via
> default_ps_max_latency_us) rather than ever being a compiled default, on any
> hardware.

Hi, Ferran,
The immediate reason for revising the previous algorithm was failure to
meet Chromebook power consumption requirements (as mentioned in commit
ebd8a93). But the problem is a generic one, excessively high power
consumption is never OK and will occasionally be caught by OEMs during
device qualification tests.
Regards,
Alexey

> Also - sorry for the fourth copy of this patch landing in your inbox on the
> 28th. That was a bookkeeping failure on my end, not a deliberate re-post; it
> went out after your reply had already arrived and should not have.

That's OK)

> Cheers,
> Ferran

[PATCH] nvme: lower default APST max latency to 25ms

[Ferran Duarri]

That one bound decides how deep a device may sleep. On a device that
advertises a non-operational state an order of magnitude slower than the
next one up, the 100ms default silently selects the slow one, and the
first read after an idle period pays that wake in full. It shows up as a
stall rather than as reduced throughput, being a one-shot cost on a cold
access rather than a steady-state penalty. The workload that prompted
this is staging large model weights from NVMe, where a cold mmap fault
on a multi-gigabyte checkpoint is exactly that access.

Measured on a Samsung SSD 990 EVO Plus 4TB (fw 2B2QKXG7), which
advertises two non-operational states:

  ps 3   exit  4.6ms   0.0800W
  ps 4   exit 43.0ms   0.0070W

At 100000 the APST table targets ps 4; at 25000 it targets ps 3. Cold
4KiB O_DIRECT reads after an idle period, 60 trials per setting, the two
settings interleaved trial by trial:

                     p50      p90      p99      max
  100000 (ps 4)     3.3ms   33.0ms   33.5ms   33.5ms
  25000  (ps 3)     3.2ms    3.6ms    3.7ms    4.2ms
  warm, no idle     0.2ms    0.3ms    1.7ms    3.6ms

Observed worst case falls from 33.5ms to 4.2ms. Both states measured 78%
of their advertised exit latency, which is the cross-check that the two
figures measure the same thing at two magnitudes.

The p50 at 100000 needs reading carefully: roughly five trials in six did
not finish descending to ps 4 inside the idle window and were sampled at
ps 3 depth, which pulls that row's median down to the 25000 row's value.
The ps 4 column therefore rests on the remaining sixth, where it was
tightly reproducible, 32.9ms to 33.5ms. That effect can only understate
the cost of the current default, never overstate it.

25ms is not derived from this device. It is a bound on latency an
interactive reader notices; any value between 4.6ms and 43ms behaves
identically here. The device is an existence proof that the 100ms
default admits a state far slower than the next available one, not the
source of the constant. On a device whose deepest non-operational state
exits well under 25ms this changes nothing, which is correct for a bound.

The cost is idle power. Excluding ps 4 leaves ps 3 as the deepest state
the device reaches autonomously, 0.0800W rather than 0.0070W, so roughly
73mW more on an idle drive.

This changes only the compiled-in default. default_ps_max_latency_us is
consumed once per controller in nvme_add_ctrl(), so it applies from the
kernel command line as nvme_core.default_ps_max_latency_us=. A running
controller instead follows its per-device PM QOS value
(pm_qos_latency_tolerance_us), which is how the two settings above were
compared without a reboot. Any system preferring deeper idle states can
restore the old behaviour without a rebuild.

Signed-off-by: Ferran Duarri <ferran.duarri@me.com>
---
 drivers/nvme/host/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index c3032d6ad6b1..e3038b880e8b 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -66,7 +66,7 @@ static u8 nvme_max_retries = 5;
 module_param_named(max_retries, nvme_max_retries, byte, 0644);
 MODULE_PARM_DESC(max_retries, "max number of retries a command may have");
 
-static unsigned long default_ps_max_latency_us = 100000;
+static unsigned long default_ps_max_latency_us = 25000;
 module_param(default_ps_max_latency_us, ulong, 0644);
 MODULE_PARM_DESC(default_ps_max_latency_us,
 		 "max power saving latency for new devices; use PM QOS to change per device");