Having to allocate a struct rcu_synchronize for each of the potentially
many queues here is a bit sad.
Pull just explained the start_poll_synchronize_rcu interfaces at ALPSS
last week, so I wonder if something like that would also be feasible
for SRCU, as that would come in really handy here.
Alternatively I wonder if we could simply use a single srcu_struct
in the tag_set instead of one per-queue. That would potentially
increase the number of read side critical sections
blk_mq_wait_quiesce_done would have to wait for in tagsets with
multiple queues, but I wonder how much overhead that would be in
practive.
It used to be on the hctx actually. It was moved to the request_queue
in an attempt to make parallel quiesce that didn't eventually complete
afaict.
For nvme, we never really quiesce a single namespace, so it will be a
net positive IMO. I also think that quiesce is really more a tagset
operation so I would think that its a more natural location.
The only question in my mind is regarding patch 2/2 with the subtle
ordering of nvme_set_queue_dying...
