On Tue, Jul 28, 2020 at 02:37:15AM -0700, Sagi Grimberg wrote: > >>>>> I like the tagset based interface. But the idea of doing a per-hctx >>>>> allocation and wait doesn't seem very scalable. >>>>> >>>>> Paul, do you have any good idea for an interface that waits on >>>>> multiple srcu heads? As far as I can tell we could just have a single >>>>> global completion and counter, and each call_srcu would just just >>>>> decrement it and then the final one would do the wakeup. It would just >>>>> be great to figure out a way to keep the struct rcu_synchronize and >>>>> counter on stack to avoid an allocation. >>>>> >>>>> But if we can't do with an on-stack object I'd much rather just embedd >>>>> the rcu_head in the hw_ctx. >>>> >>>> I think we can do that, please see the following patch which is against Sagi's V5: >>> >>> I don't think you can send a single rcu_head to multiple call_srcu calls. >> >> OK, then one variant is to put the rcu_head into blk_mq_hw_ctx, and put >> rcu_synchronize into blk_mq_tag_set. > > I can cook up a spin, but I still hate the fact that I have a queue that > ends up quiesced which I didn't want it to... Why do we care so much about the connect_q? Especially if we generalize it into a passthru queue that will absolutely need the quiesce hopefully soon.
