mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: stuart hayes <stuart.w.hayes@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: 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>,
	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>
Subject: Re: [PATCH v10 0/5] shut down devices asynchronously
Date: Thu, 3 Jul 2025 10:59:10 -0500	[thread overview]
Message-ID: <893b1fd8-9f34-4118-9c53-05a1295850fd@gmail.com> (raw)
In-Reply-To: <20250703114656.GE17686@lst.de>

On 7/3/2025 6:46 AM, Christoph Hellwig wrote:
> On Wed, Jun 25, 2025 at 03:18:48PM -0500, Stuart Hayes wrote:
>> 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
> 
> Given all these thread spawning issues, why can't we just go back
> to the approach that kicks off shutdown asynchronously and then waits
> for it without spawning all these threads?
> 

If you mean for drivers to have an extra call like shutdown_start() 
that's called for all devices before waiting for any of them to finish, 
it seems like that would just push the work of spawning a shutdown 
thread onto the individual drivers (unless they just had a single 
command they issue to the device that takes all the time), and 
synchronization might be more of an issue since shutdown_start() could 
be called on a device before that device's children or dependents have 
finished shutting down.

With the async shutdown code from this patch set in place, any driver 
can be fully enabled to shut down devices asynchronously with no work 
other than setting a flag to allow it, and no device will start shutting 
down until its children and dependents have finished.

I think the main issue in the previous version of this patch was just 
that it was taking too long on smaller systems to spawn a thread for 
every single device shutdown, when most or all of those devices were 
shutting down synchronously anyway. This version of the patch solves 
that issue... it should only spawn on the order of roughly 2N threads on 
systems with N async shutdown devices, and it improves the kernel async 
code to make synchronizing to a cookie faster, too.


  parent reply	other threads:[~2025-07-03 15:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-25 20:18 Stuart Hayes
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 [this message]
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=893b1fd8-9f34-4118-9c53-05a1295850fd@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

all inboxes | Powered by JetHome®