Christoph Hellwig <hch@xxxxxx> writes:
> On Mon, May 18, 2020 at 08:38:04PM +0200, Thomas Gleixner wrote:
>> > Shouldn't all the per-cpu kthreads also stop as part of the offlining?
>> > If they don't quiesce before the new blk-mq stop state I think we need
>> > to make sure they do. It is rather pointless to quiesce the requests
>> > if a thread that can submit I/O is still live.
>>
>> Which kthreads are you talking about?
>
> I think PF_KTHREAD threads bound to single cpu will usually be
> workqueues, yes.
>
>> Workqueues? CPU bound workqueues are shut down in
>> CPUHP_AP_WORKQUEUE_ONLINE state.
>
> That's what I mean. If we shut down I/O before that happend we'd have
> a problem, but as I expected your state machine is smarter than that :)
It would have been a problem with the old notifier mess to actually
figure out what runs when. But with the explicit states it should be
pretty easy to find a spot which meets your requirements :)
Thanks,
tglx
