On 11/4/21 7:23 AM, Asutosh Das (asd) wrote:
In the current clock scaling code, the expectation is to scale up as
soon as possible.
For e.g. say, the current gear is G1 and there're pending requests in
the queue but the DBR is empty and there's a decision to scale up.
During scale-up, if the queues are frozen, wouldn't those requests be
issued to the driver and executed in G1 instead of G4?
I think this would lead to higher run to run variance in performance.
Hi Asutosh,
My understanding of the current clock scaling implementation is as
follows (please correct me if I got anything wrong):
* ufshcd_clock_scaling_prepare() is called before clock scaling happens
and ufshcd_clock_scaling_unprepare() is called after clock scaling has
finished.
* ufshcd_clock_scaling_prepare() calls ufshcd_scsi_block_requests() and
ufshcd_wait_for_doorbell_clr().
* ufshcd_wait_for_doorbell_clr() waits until both the UTP Transfer
Request List Doorbell Register and UTP Task Management Request List
DoorBell Register are zero. Hence, it waits until all pending SCSI
commands, task management commands and device commands have finished.
As far as I can see from a conceptual viewpoint there is no difference
between calling ufshcd_wait_for_doorbell_clr() or freezing the request
queues. There is an implementation difference however:
blk_mq_freeze_queue() waits for an RCU grace period. This can introduce
an additional delay of several milliseconds compared to
ufshcd_wait_for_doorbell_clr(). If this is a concern I can look into
expediting the RCU grace period during clock scaling.
Thanks,
Bart.
