From: Stuart Hayes <stuart.w.hayes@gmail.com>
To: linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Martin Belanger <Martin.Belanger@dell.com>,
Oliver O'Halloran <oohall@gmail.com>,
Daniel Wagner <dwagner@suse.de>, Keith Busch <kbusch@kernel.org>,
Lukas Wunner <lukas@wunner.de>,
David Jeffery <djeffery@redhat.com>,
Jeremy Allison <jallison@ciq.com>, Jens Axboe <axboe@fb.com>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org,
Nathan Chancellor <nathan@kernel.org>,
Jan Kiszka <jan.kiszka@seimens.com>,
Bert Karwatzki <spasswolf@web.de>
Cc: Stuart Hayes <stuart.w.hayes@gmail.com>
Subject: [PATCH v10 0/5] shut down devices asynchronously
Date: Wed, 25 Jun 2025 15:18:48 -0500 [thread overview]
Message-ID: <20250625201853.84062-1-stuart.w.hayes@gmail.com> (raw)
This adds the ability for the kernel to shutdown devices asynchronously.
Only devices with drivers that enable it are shut down asynchronously.
This can dramatically reduce system shutdown/reboot time on systems that
have multiple devices that take many seconds to shut down (like certain
NVMe drives). On one system tested, the shutdown time went from 11 minutes
without this patch to 55 seconds with the patch.
Changes from V9:
Address resource and timing issues when spawning a unique async thread
for every device during shutdown:
* Make the asynchronous threads able to shut down multiple devices,
instead of spawning a unique thread for every device.
* Modify core kernel async code with a custom wake function so it
doesn't wake up threads waiting to synchronize every time the cookie
changes
Changes from V8:
Deal with shutdown hangs resulting when a parent/supplier device is
later in the devices_kset list than its children/consumers:
* Ignore sync_state_only devlinks for shutdown dependencies
* Ignore shutdown_after for devices that don't want async shutdown
* Add a sanity check to revert to sync shutdown for any device that
would otherwise wait for a child/consumer shutdown that hasn't
already been scheduled
Changes from V7:
Do not expose driver async_shutdown_enable in sysfs.
Wrapped a long line.
Changes from V6:
Removed a sysfs attribute that allowed the async device shutdown to be
"on" (with driver opt-out), "safe" (driver opt-in), or "off"... what was
previously "safe" is now the only behavior, so drivers now only need to
have the option to enable or disable async shutdown.
Changes from V5:
Separated into multiple patches to make review easier.
Reworked some code to make it more readable
Made devices wait for consumers to shut down, not just children
(suggested by David Jeffery)
Changes from V4:
Change code to use cookies for synchronization rather than async domains
Allow async shutdown to be disabled via sysfs, and allow driver opt-in or
opt-out of async shutdown (when not disabled), with ability to control
driver opt-in/opt-out via sysfs
Changes from V3:
Bug fix (used "parent" not "dev->parent" in device_shutdown)
Changes from V2:
Removed recursive functions to schedule children to be shutdown before
parents, since existing device_shutdown loop will already do this
Changes from V1:
Rewritten using kernel async code (suggested by Lukas Wunner)
David Jeffery (1):
kernel/async: streamline cookie synchronization
Stuart Hayes (4):
driver core: don't always lock parent in shutdown
driver core: separate function to shutdown one device
driver core: shut down devices asynchronously
nvme-pci: Make driver prefer asynchronous shutdown
drivers/base/base.h | 8 ++
drivers/base/core.c | 210 +++++++++++++++++++++++++++++-----
drivers/nvme/host/pci.c | 1 +
include/linux/device/driver.h | 2 +
kernel/async.c | 42 ++++++-
5 files changed, 236 insertions(+), 27 deletions(-)
--
2.39.3
next reply other threads:[~2025-06-25 20:37 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 20:18 Stuart Hayes [this message]
2025-06-25 20:18 ` [PATCH v10 1/5] kernel/async: streamline cookie synchronization Stuart Hayes
2025-07-08 22:17 ` Sultan Alsawaf
2025-06-25 20:18 ` [PATCH v10 2/5] driver core: don't always lock parent in shutdown Stuart Hayes
2025-07-01 8:50 ` Greg Kroah-Hartman
2025-07-02 14:38 ` David Jeffery
2025-06-25 20:18 ` [PATCH v10 3/5] driver core: separate function to shutdown one device Stuart Hayes
2025-06-25 20:18 ` [PATCH v10 4/5] driver core: shut down devices asynchronously Stuart Hayes
2025-06-25 20:18 ` [PATCH v10 5/5] nvme-pci: Make driver prefer asynchronous shutdown Stuart Hayes
2025-06-30 20:33 ` [PATCH v10 0/5] shut down devices asynchronously Michael Kelley
2025-06-30 22:02 ` Laurence Oberman
2025-07-03 11:46 ` Christoph Hellwig
2025-07-03 15:41 ` Jeremy Allison
2025-07-04 13:45 ` David Jeffery
2025-07-04 16:26 ` Sultan Alsawaf
2025-07-07 15:34 ` David Jeffery
2025-07-07 20:49 ` stuart hayes
2025-07-08 0:00 ` Sultan Alsawaf
2025-07-08 21:47 ` Sultan Alsawaf
2025-07-08 21:31 ` Sultan Alsawaf
2025-07-03 15:59 ` stuart hayes
2025-07-04 13:38 ` David Jeffery
2025-07-04 13:44 ` Greg Kroah-Hartman
2025-07-04 14:09 ` David Jeffery
2025-07-04 14:13 ` Greg Kroah-Hartman
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=20250625201853.84062-1-stuart.w.hayes@gmail.com \
--to=stuart.w.hayes@gmail.com \
--cc=Martin.Belanger@dell.com \
--cc=axboe@fb.com \
--cc=djeffery@redhat.com \
--cc=dwagner@suse.de \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=jallison@ciq.com \
--cc=jan.kiszka@seimens.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=lukas@wunner.de \
--cc=nathan@kernel.org \
--cc=oohall@gmail.com \
--cc=rafael@kernel.org \
--cc=sagi@grimberg.me \
--cc=spasswolf@web.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).