[PATCH v3 1/2] blk-mq: add async quiesce interface

[Sagi Grimberg]

>>>>>> It is at the end and contains exactly what is needed to synchronize. Not
>>>>> The sync is simply single global synchronize_rcu(), and why bother to add
>>>>> extra >=40bytes for each hctx.
>>>>>
>>>>>> sure what you mean by reuse hctx->srcu?
>>>>> You already reuses hctx->srcu, but not see reason to add extra rcu_synchronize
>>>>> to each hctx for just simulating one single synchronize_rcu().
>>>>
>>>> To sync srcu together, the extra bytes must be needed, seperate blocking
>>>> and non blocking queue to two hctx may be a not good choice.
>>>>
>>>> There is two choice: the struct rcu_synchronize is added in hctx or in srcu.
>>>> Though add rcu_synchronize in srcu has a  weakness: the extra bytes is
>>>> not need if which do not need batch sync srcu, I still think it's better
>>>> for the SRCU to provide the batch synchronization interface.
>>>
>>> The 'struct rcu_synchronize' can be allocated from heap or even stack(
>>> if no too many NSs), which is just one shot sync and the API is supposed
>>> to be called in slow path. No need to allocate it as long lifetime variable.
>>> Especially 'struct srcu_struct' has already been too fat.
>>
>> Stack is not suitable, stack can not provide so many space for
> 
> Stack is fine if number of NS is small, for example, most of times,
> there is just one NS.

I prefer a single code-path, so stack is not good.

>> many name space. Heap maybe a choice, but need to add abnormal treat
>> when alloc memory failed, Thus io pause time can not be ensured.
>> So the extra space may must be needed for batch srcu sync.
> 
> In case of allocation failure, you can switch to synchronize_srcu() simply.

that is possible, but I still prefer to support both srcu and rcu hctx
in a single interface so I don't need to have different code paths in
nvme (or other drivers).