From: Christoph Hellwig <hch@lst.de>
To: guzebing <guzebing1612@gmail.com>
Cc: kbusch@kernel.org, axboe@kernel.dk, hch@lst.de, sagi@grimberg.me,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Guzebing <guzebing@bytedance.com>
Subject: Re: [PATCH] nvme: make firmware activation poll interval configurable
Date: Thu, 9 Jul 2026 08:42:33 +0200 [thread overview]
Message-ID: <20260709064233.GA18381@lst.de> (raw)
In-Reply-To: <20260627010610.47768-1-guzebing1612@gmail.com>
On Sat, Jun 27, 2026 at 09:06:10AM +0800, guzebing wrote:
> From: Guzebing <guzebing@bytedance.com>
>
> nvme_fw_act_work() polls the controller processing-paused status every
> 100 ms while firmware activation is pending. Some devices can complete
> online activation in only a few hundred milliseconds, so the fixed
> interval can add noticeable latency before the driver observes
> completion.
>
> Add an nvme_core.fw_act_poll_interval_ms module parameter to make the
> poll interval tunable. Keep the default at 100 ms to preserve existing
> behavior, and accept values from 10 ms to 100 ms so systems that need
> faster completion detection can opt in to a shorter interval.
>
> Signed-off-by: Guzebing <guzebing@bytedance.com>
> ---
> We recently observed this issue while performing online firmware
> updates for Gen5 NVMe SSDs in a production environment.
>
> During firmware activation, the kernel quiesces I/O. Detecting the end
> of firmware activation earlier lets the driver unquiesce I/O earlier,
> which is important for the long-tail I/O latency of production
> workloads.
What value does this device report in the Maximum Time for Firmware
Activation (MTFA) field? It might make sense to scale the polling
time as a fraction of that instead of requiring a manual override.
next prev parent reply other threads:[~2026-07-09 6:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-27 1:06 [PATCH] nvme: make firmware activation poll interval configurable guzebing
2026-07-06 6:33 ` guzebing
2026-07-09 6:42 ` Christoph Hellwig [this message]
2026-07-09 9:06 ` guzebing
2026-07-09 15:07 ` Keith Busch
2026-07-10 9:20 ` guzebing
2026-07-13 6:45 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260709064233.GA18381@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=guzebing1612@gmail.com \
--cc=guzebing@bytedance.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.