Christoph Hellwig <hch@xxxxxx> writes:
> On Mon, May 18, 2020 at 10:11:07PM +0800, Ming Lei wrote:
>> On Mon, May 18, 2020 at 03:16:34PM +0200, Christoph Hellwig wrote:
>> > On Mon, May 18, 2020 at 07:54:54PM +0800, Ming Lei wrote:
>> > >
>> > > I guess I misunderstood your point, sorry for that.
>> > >
>> > > The requirement is just that the request needs to be allocated on one online
>> > > CPU after INACTIVE is set, and we can use a workqueue to do that.
>> >
>> > I've looked over the code again, and I'm really not sure why we need that.
>> > Presumable the CPU hotplug code ensures tasks don't get schedule on the
>> > CPU running the shutdown state machine, so if we just do a retry of the
>>
>> percpu kthread still can be scheduled on the cpu to be online, see
>> is_cpu_allowed(). And bound wq has been used widely in fs code.
>
> s/to be online/to be offlined/ I guess.
>
> 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?
Workqueues? CPU bound workqueues are shut down in
CPUHP_AP_WORKQUEUE_ONLINE state.
Thanks,
tglx
