linux-kernel - Re: [PATCH 1/2] scsi: ufs: Suspend clk scaling on no request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 27 Jun 2024 13:39:51 +0530
From: Ram Prakash Gupta <quic_rampraka@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        "Martin K.
 Petersen" <martin.petersen@...cle.com>,
        Manivannan Sadhasivam
	<manivannan.sadhasivam@...aro.org>,
        Alim Akhtar <alim.akhtar@...sung.com>,
        Avri Altman <avri.altman@....com>,
        Bart Van Assche <bvanassche@....org>, <linux-scsi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <quic_cang@...cinc.com>, <quic_nguyenb@...cinc.com>,
        <quic_pragalla@...cinc.com>, <quic_nitirawa@...cinc.com>
Subject: Re: [PATCH 1/2] scsi: ufs: Suspend clk scaling on no request



On 6/26/2024 11:14 PM, Dmitry Baryshkov wrote:
> On Wed, Jun 26, 2024 at 04:00:32PM GMT, Ram Prakash Gupta wrote:
>> Currently ufs clk scaling is getting suspended only when the
>> clks are scaled down, but next when high load is generated its
>> adding a huge amount of latency in scaling up the clk and complete
>> the request post that.
>>
>> Now if the scaling is suspended in its existing state, and when high
>> load is generated it is helping improve the random performance KPI by
>> 28%. So suspending the scaling when there is no request. And the clk
>> would be put in low scaled state when the actual request load is low.
>>
>> Making this change as optional for other vendor by having the check
>> enabled using vops as for some vendor suspending without bringing the
>> clk in low scaled state might have impact on power consumption on the
>> SoC.
>>
>> Signed-off-by: Ram Prakash Gupta <quic_rampraka@...cinc.com>
>> ---
>>   drivers/ufs/core/ufshcd.c | 3 ++-
>>   include/ufs/ufshcd.h      | 1 +
>>   2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
>> index 1b65e6ae4137..0dc9928ae18d 100644
>> --- a/drivers/ufs/core/ufshcd.c
>> +++ b/drivers/ufs/core/ufshcd.c
>> @@ -1560,7 +1560,8 @@ static int ufshcd_devfreq_target(struct device *dev,
>>   		ktime_to_us(ktime_sub(ktime_get(), start)), ret);
>>   
>>   out:
>> -	if (sched_clk_scaling_suspend_work && !scale_up)
>> +	if (sched_clk_scaling_suspend_work && (!scale_up ||
>> +				hba->clk_scaling.suspend_on_no_request))
> 
> Really a nit: moving !scale_up to the next line would make easier to
> read.
> 
thanks will take care in next patchset.

>>   		queue_work(hba->clk_scaling.workq,
>>   			   &hba->clk_scaling.suspend_work);
>>   
>> diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
>> index bad88bd91995..c14607f2890b 100644
>> --- a/include/ufs/ufshcd.h
>> +++ b/include/ufs/ufshcd.h
>> @@ -457,6 +457,7 @@ struct ufs_clk_scaling {
>>   	bool is_initialized;
>>   	bool is_busy_started;
>>   	bool is_suspended;
>> +	bool suspend_on_no_request;
>>   };
>>   
>>   #define UFS_EVENT_HIST_LENGTH 8
>> -- 
>> 2.17.1
>>
>