Re: [PATCH] scsi: ufs: Make ufshcd_clock_scaling_prepare() compatible with MCQ

[Bart Van Assche <bvanassche@acm.org>]

On 7/3/25 1:29 AM, Ziqi Chen wrote:
> Although patch functional is OK, but I found this patch will increase
> the latency of ufshcd_clock_scaling_prepare():
> 
> MTP 8550 (upstream kernel):
> Original:
>   spent: 226302 ns, avg: 2135214 ns, count: 200, total:427042923 ns
> with patch:
>   spent: 1213333 ns, avg: 4583551 ns, count: 200, total:916710316 ns
> 
> MTP 8650 (upstream kernel):
> Original:
>   spent: 2013386 ns, avg: 1464596 ns, count: 150, total:219689530 ns
> with patch:
>   spent: 2718802 ns, avg: 4329696 ns, count: 150, total:649454539 ns
> 
> MTP8850 (downstream kernel)
> Original:
>   spent: 144323 ns, avg: 1080332 ns, count: 2005, total:2166066242 ns
> with patch:
>   spent: 2530208 ns, avg: 1307159 ns, count: 2005, total:2620855033 ns

That's unfortunate ...

> I think this increament is come from you replaced blk_mq_quiesce_queue()
> with blk_freeze_queue(), as my understading , the blk_mq_quiesce_queue()
> just only block new IO be dispatched to hardware queue but the
> blk_freeze_queue() will freeze whole queue and wait all IOs get
> complete.

Hmm ... both blk_freeze_queue() and the loop that calls
ufshcd_pending_cmds() should wait for all pending commands to finish. So
the latency increase probably comes from the synchronize_rcu_expedited()
call.

> I am not understand you said "ufshcd_wait_for_doorbell_clr() supports
> the legacy doorbell mode but not MCQ". In ufshcd_wait_for_doorbell_clr()
> , tr_pending = ufshcd_pending_cmds(hba) is counted from budget_map, not
> read from legacy doorbell, it is used to get inflight cmds for MCQ mode.

That was a misunderstanding from my side. Since the current code already
supports MCQ and my patch doesn't improve the clock scaling latency,
let's drop this patch.

Thanks,

Bart.