Re: [PATCH RFC] scsi: ufs-core: Do not use clk_scaling_lock in ufshcd_queuecommand()

["Asutosh Das (asd)" <asutoshd@codeaurora.org>]

On 11/3/2021 10:06 AM, Bart Van Assche wrote:
> On 11/3/21 12:46 AM, Adrian Hunter wrote:
>> On 02/11/2021 22:49, Bart Van Assche wrote:
>>>   static int ufshcd_clock_scaling_prepare(struct ufs_hba *hba)
>>>   {
>>> -    #define DOORBELL_CLR_TOUT_US        (1000 * 1000) /* 1 sec */
>>>       int ret = 0;
>>> +
>>>       /*
>>> -     * make sure that there are no outstanding requests when
>>> -     * clock scaling is in progress
>>> +     * Make sure that there are no outstanding requests while clock 
>>> scaling
>>> +     * is in progress. Since the error handler may submit TMFs, 
>>> limit the
>>> +     * time during which to block hba->tmf_queue in order not to 
>>> block the
>>> +     * UFS error handler.
>>> +     *
>>> +     * Since ufshcd_exec_dev_cmd() and 
>>> ufshcd_issue_devman_upiu_cmd() lock
>>> +     * the clk_scaling_lock before calling blk_get_request(), lock
>>> +     * clk_scaling_lock before freezing the request queues to prevent a
>>> +     * deadlock.
>>>        */
>>> -    ufshcd_scsi_block_requests(hba);
>>
>> How are requests from LUN queues blocked?
> 
> I will add blk_freeze_queue() calls for the LUNs.
> 
> Thanks,
> 
> Bart.
Hi Bart,

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.

What do you think?

Thanks,
-asd

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project