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] [thread-next>] [day] [month] [year] [list]

Message-ID: <62m4bfyhgzidseda2mduetaq4b2onlpjkxzsc3skc3fx7iw3xh@eyt2nwn2cuoi>
Date: Wed, 26 Jun 2024 20:44:07 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Ram Prakash Gupta <quic_rampraka@...cinc.com>
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 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.

>  		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
> 

-- 
With best wishes
Dmitry