linux-kernel - Re: [PATCH 00/15] cpufreq: simplify boost handling

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: <20250127033228.abeqhrxoprqw5b4e@vireshk-i7>
Date: Mon, 27 Jan 2025 09:02:28 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Alyssa Rosenzweig <alyssa@...enzweig.io>,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	Cristian Marussi <cristian.marussi@....com>,
	"Gautham R. Shenoy" <gautham.shenoy@....com>,
	Hector Martin <marcan@...can.st>,
	Huacai Chen <chenhuacai@...nel.org>, Huang Rui <ray.huang@....com>,
	Madhavan Srinivasan <maddy@...ux.ibm.com>,
	Mario Limonciello <mario.limonciello@....com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Naveen N Rao <naveen@...nel.org>,
	Nicholas Piggin <npiggin@...il.com>,
	Perry Yuan <perry.yuan@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	Sven Peter <sven@...npeter.dev>, WANG Xuerui <kernel@...0n.name>,
	linux-pm@...r.kernel.org,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Lifeng Zheng <zhenglifeng1@...wei.com>, arm-scmi@...r.kernel.org,
	asahi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, loongarch@...ts.linux.dev
Subject: Re: [PATCH 00/15] cpufreq: simplify boost handling

On 24-01-25, 12:05, Rafael J. Wysocki wrote:
> On Fri, Jan 24, 2025 at 9:58 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> >
> > Hello,
> >
> > The boost feature can be controlled at two levels currently, driver
> > level (applies to all policies) and per-policy.
> >
> > Currently most of the drivers enables driver level boost support from the
> > per-policy ->init() callback, which isn't really efficient as that gets called
> > for each policy and then there is online/offline path too where this gets done
> > unnecessarily.
> >
> > Also it is possible to have a scenario where not all cpufreq policies support
> > boost frequencies. And letting sysfs (or other parts of the kernel) enable boost
> > feature for that policy isn't correct.
> >
> > Simplify and cleanup handling of boost to solve these issues.
> 
> I guess this depends on the previous series?

Yes my series and the boost related patches in your tree.

-- 
viresh