[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0jUuv7+j5M7xKhC2BdNdj-t==f56GbSDK_Tfrr7=pMcLQ@mail.gmail.com>
Date: Wed, 30 Mar 2022 13:13:30 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Lukas Wunner <lukas@...ner.de>
Cc: Keith Busch <kbusch@...nel.org>,
Tanjore Suresh <tansuresh@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-nvme <linux-nvme@...ts.infradead.org>,
Linux PCI <linux-pci@...r.kernel.org>
Subject: Re: [PATCH v1 0/3] Asynchronous shutdown interface and example implementation
On Wed, Mar 30, 2022 at 8:25 AM Lukas Wunner <lukas@...ner.de> wrote:
>
> On Tue, Mar 29, 2022 at 08:07:51PM -0600, Keith Busch wrote:
> > Thanks, I agree we should improve shutdown times. I tried a while ago, but
> > lost track to follow up at the time. Here's the reference, fwiw, though it
> > may be out of date :):
> >
> > http://lists.infradead.org/pipermail/linux-nvme/2014-May/000826.html
> >
> > The above solution is similiar to how probe waits on an async domain.
> > Maybe pci can schedule the async shutdown instead of relying on low-level
> > drivers so that everyone implicitly benefits instead of just nvme? I'll
> > double-check if that's reasonable, but I'll look through this series too.
>
> Using the async API seems much more reasonable than adding new callbacks.
>
> However I'd argue that it shouldn't be necessary to amend any drivers,
> this should all be doable in the driver core: Basically a device needs
> to wait for its children and device links consumers to shutdown, apart
> from that everything should be able to run asynchronously.
Well, this is done already in the system-wide and hibernation paths.
It should be possible to implement asynchronous shutdown analogously.
Powered by blists - more mailing lists