[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190205151632.GA28064@localhost.localdomain>
Date: Tue, 5 Feb 2019 08:16:36 -0700
From: Keith Busch <keith.busch@...el.com>
To: Hannes Reinecke <hare@...e.com>
Cc: John Garry <john.garry@...wei.com>, Hannes Reinecke <hare@...e.de>,
Thomas Gleixner <tglx@...utronix.de>,
Christoph Hellwig <hch@....de>,
Marc Zyngier <marc.zyngier@....com>,
"axboe@...nel.dk" <axboe@...nel.dk>,
Peter Zijlstra <peterz@...radead.org>,
Michael Ellerman <mpe@...erman.id.au>,
Linuxarm <linuxarm@...wei.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>
Subject: Re: Question on handling managed IRQs when hotplugging CPUs
On Tue, Feb 05, 2019 at 04:10:47PM +0100, Hannes Reinecke wrote:
> On 2/5/19 3:52 PM, Keith Busch wrote:
> > Whichever layer dispatched the IO to a CPU specific context should
> > be the one to wait for its completion. That should be blk-mq for most
> > block drivers.
> >
> Indeed.
> But we don't provide any mechanisms for that ATM, right?
>
> Maybe this would be a topic fit for LSF/MM?
Right, there's nothing handling this now, and sounds like it'd be a good
discussion to bring to the storage track.
Powered by blists - more mailing lists