linux-kernel - Re: [RFC][PATCH 1/3] PM /devfreq: add user frequency limits into devfreq struct

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]

Date:   Wed, 3 Feb 2021 10:21:45 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Chanwoo Choi <cw00.choi@...sung.com>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        vireshk@...nel.org, rafael@...nel.org, daniel.lezcano@...aro.org,
        Dietmar.Eggemann@....com, amitk@...nel.org, rui.zhang@...el.com,
        myungjoo.ham@...sung.com, kyungmin.park@...sung.com
Subject: Re: [RFC][PATCH 1/3] PM /devfreq: add user frequency limits into
 devfreq struct

Hi Chanwoo,

Thank you for looking at this.

On 2/3/21 10:11 AM, Chanwoo Choi wrote:
> Hi Lukasz,
> 
> When accessing the max_freq and min_freq at devfreq-cooling.c,
> even if can access 'user_max_freq' and 'lock' by using the 'devfreq' instance,
> I think that the direct access of variables (lock/user_max_freq/user_min_freq)
> of struct devfreq are not good.
> 
> Instead, how about using the 'DEVFREQ_TRANSITION_NOTIFIER'
> notification with following changes of 'struct devfreq_freq'?

I like the idea with devfreq notification. I will have to go through the
code to check that possibility.

> Also, need to add codes into devfreq_set_target() for initializing
> 'new_max_freq' and 'new_min_freq' before sending the DEVFREQ_POSTCHANGE
> notification.
> 
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 147a229056d2..d5726592d362 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -207,6 +207,8 @@ struct devfreq {
>   struct devfreq_freqs {
>          unsigned long old;
>          unsigned long new;
> +       unsigned long new_max_freq;
> +       unsigned long new_min_freq;
>   };
> 
> 
> And I think that new 'user_min_freq'/'user_max_freq' are not necessary.
> You can get the current max_freq/min_freq by using the following steps:
> 
> 	get_freq_range(devfreq, &min_freq, &max_freq);
> 	dev_pm_opp_find_freq_floor(pdev, &min_freq);
> 	dev_pm_opp_find_freq_floor(pdev, &max_freq);
> 
> So that you can get the 'max_freq/min_freq' and then
> initialize the 'freqs.new_max_freq and freqs.new_min_freq'
> with them as following:
> 
> in devfreq_set_target()
> 	get_freq_range(devfreq, &min_freq, &max_freq);
> 	dev_pm_opp_find_freq_floor(pdev, &min_freq);
> 	dev_pm_opp_find_freq_floor(pdev, &max_freq);
> 	freqs.new_max_freq = min_freq;
> 	freqs.new_max_freq = max_freq;
> 	devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);

I will plumb it in and check that option. My concern is that function
get_freq_range() would give me the max_freq value from PM QoS, which
might be my thermal limit - lower that user_max_freq. Then I still
need

I've been playing with PM QoS notifications because I thought it would
be possible to be notified in thermal for all new set values - even from
devfreq sysfs user max_freq write, which has value higher that the
current limit set by thermal governor. Unfortunately PM QoS doesn't
send that information by design. PM QoS also by desing won't allow
me to check first two limits in the plist - which would be thermal
and user sysfs max_freq.

I will experiment with this notifications and share the results.
That you for your comments.

Regards,
Lukasz