Re: [PATCH 5/9] blk-mq: don't set data->ctx and data->hctx in blk_mq_alloc_request_hctx

Christoph Hellwig [off-list ref] writes:

On Mon, May 18, 2020 at 10:11:07PM +0800, Ming Lei wrote:

quoted

On Mon, May 18, 2020 at 03:16:34PM +0200, Christoph Hellwig wrote:

quoted

On Mon, May 18, 2020 at 07:54:54PM +0800, Ming Lei wrote:

quoted

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