linux-kernel - Re: [PATCH] cpufreq/schedutil: Only bind threads if needed

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]

Message-ID: <20241001100004.nbok7s7zmgbcmqnz@vireshk-i7>
Date: Tue, 1 Oct 2024 15:30:04 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Christian Loehle <christian.loehle@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-pm <linux-pm@...r.kernel.org>,
	Qais Yousef <qyousef@...alina.io>,
	Juri Lelli <juri.lelli@...hat.com>, Ingo Molnar <mingo@...hat.com>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Pierre Gondois <pierre.gondois@....com>
Subject: Re: [PATCH] cpufreq/schedutil: Only bind threads if needed

On 12-09-24, 17:41, Rafael J. Wysocki wrote:
> On Thu, Sep 12, 2024 at 3:53 PM Christian Loehle
> <christian.loehle@....com> wrote:
> >
> > Remove the unconditional binding of sugov kthreads to the affected CPUs
> > if the cpufreq driver indicates that updates can happen from any CPU.
> > This allows userspace to set affinities to either save power (waking up
> > bigger CPUs on HMP can be expensive) or increasing performance (by
> > letting the utilized CPUs run without preemption of the sugov kthread).
> >
> > Without this patch the behavior of sugov threads will basically be a
> > boot-time dice roll on which CPU of the PD has to handle all the
> > cpufreq updates. With the recent decreases of update filtering these
> > two basic problems become more and more apparent:
> > 1. The wake_cpu might be idle and we are waking it up from another
> > CPU just for the cpufreq update. Apart from wasting power, the exit
> > latency of it's idle state might be longer than the sugov threads
> > running time, essentially delaying the cpufreq update unnecessarily.
> > 2. We are preempting either the requesting or another busy CPU of the
> > PD, while the update could be done from a CPU that we deem less
> > important and pay the price of an IPI and two context-switches.
> >
> > The change is essentially not setting PF_NO_SETAFFINITY on
> > dvfs_possible_from_any_cpu, no behavior change if userspace doesn't
> > touch affinities.
> 
> I'd like to hear from Viresh on this.

Looks good to me.

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

-- 
viresh