Re: [PATCH] nvme: make firmware activation poll interval configurable

guzebing <[email protected]>
Newsgroups org.infradead.lists.linux-nvme,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

On 7/9/26 11:07 PM, Keith Busch wrote:
> On Thu, Jul 09, 2026 at 05:06:11PM +0800, guzebing wrote:
>> The Samsung PM9D3a Gen5 SSD reports MTFA = 10, i.e. 1000 ms.
>>
>> I also checked another device, an Intel/Solidigm P5520 Gen4 drive.  It
>> reports MTFA = 100, i.e. 10000 ms, while the observed online activation
>> time is about 800 ms.
>>
>> I agree that deriving the polling interval from MTFA would be better
>> than adding a module parameter.  Given that MTFA is a conservative upper
>> bound rather than a good estimate of the common activation time, would
>> using a small fraction of it, for example MTFA / 100 clamped to 10..100
>> ms, be a reasonable policy for v2?
>>
>> That would give 10 ms for the PM9D3a device above, while keeping the
>> current 100 ms interval for the P5520 case and for large-MTFA devices.
> 
> nvme_wait_ready() has a similar polling loop on the csts register, but
> it does a udelay_range for 1-2 msecs no matter what the ready timeout
> is. Maybe just do the same for consistency?

Keith, using the same 1-2 ms sleep range as nvme_wait_ready() looks
simpler to me as well.

I measured two long-running nvme_wait_ready() calls in the normal
nvme-pci NVMe controller-reset path for a live Intel P5520
(SSDPF2KX076T1), not the PCIe FLR fallback:

  nvme_disable_ctrl() cleared NVME_CC_ENABLE in ctrl->ctrl_config,
  wrote the cached value to CC, and then waited for CSTS.RDY == 0:
  1353 ms

  nvme_enable_ctrl() set NVME_CC_ENABLE in ctrl->ctrl_config, wrote
  the cached value to CC, and then waited for CSTS.RDY == 1: 1070 ms

Both long-running waits used an effective timeout argument of 30
seconds. The same drive reports MTFA = 100 (10 seconds), while its
observed online firmware activation time was about 800 ms. Thus, on
this device, the ready waits already use the 1-2 ms sleep range for
longer than the observed firmware activation.

Thanks both for the suggestions. Christoph, would this approach work
for you as well? If so, I can respin v2 to drop the module parameter
and replace msleep(100) with usleep_range(1000, 2000) in
nvme_fw_act_work().
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.