linux-kernel - Re: [PATCH v2] cpufreq: Support per-policy performance boost

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: <20230825063926.n4o7cp6x56r5i2it@vireshk-i7>
Date:   Fri, 25 Aug 2023 12:09:26 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Jie Zhan <zhanjie9@...ilicon.com>
Cc:     rafael@...nel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linuxarm@...wei.com,
        xuwei5@...wei.com, wanghuiqiang@...wei.com,
        jonathan.cameron@...wei.com, wangxiongfeng2@...wei.com
Subject: Re: [PATCH v2] cpufreq: Support per-policy performance boost

On 22-08-23, 20:48, Jie Zhan wrote:
> The boost control currently applies to the whole system.  However, users
> may prefer to boost a subset of cores in order to provide prioritized
> performance to workloads running on the boosted cores.
> 
> Enable per-policy boost by adding a 'boost' sysfs interface under each
> policy path.  This can be found at:
> 
> 	/sys/devices/system/cpu/cpufreq/policy<*>/boost
> 
> Same to the global boost switch, writing 1/0 to the per-policy 'boost'
> enables/disables boost on a cpufreq policy respectively.
> 
> The user view of global and per-policy boost controls should be:
> 
> 1. Enabling global boost initially enables boost on all policies, and
> per-policy boost can then be enabled or disabled individually, given that
> the platform does support so.
> 
> 2. Disabling global boost makes the per-policy boost interface illegal.
> 
> Signed-off-by: Jie Zhan <zhanjie9@...ilicon.com>
> Reviewed-by: Wei Xu <xuwei5@...ilicon.com>
> ---
> A possible question could be: why not just limiting 'scaling_max_freq'?
> Well, the fundamental difference is that per-policy boost could be more
> user-friendly.  When global boost is enabled, it is not straightforward
> to figure out the base frequency for setting 'scaling_max_freq' to a
> non-boost value. Also, this is supposed to take effect on the physical
> upper frequency limit, reflected through 'cpuinfo_max_freq'.
> 
> v1->v2:
> - Rename the interface from 'local_boost' to 'boost'.
> - Illegalize writing 0 to per-policy even if global boost is off.
> - Show the per-policy 'boost' file only when ->set_boost() is available.
> 
> v1: https://lore.kernel.org/linux-pm/20230724075827.4160512-1-zhanjie9@hisilicon.com/

Looks good now, thanks.

Acked-by: Viresh Kumar <viresh.kumar@...aro.org>

-- 
viresh