linux-kernel - Re: [PATCH v2] cpufreq: queue policy->update work to a dedicated thread

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: <CAJZ5v0jUqzT_+7VxmRqE_xAWzNCyfiUim-Hz9FaF7G0MuUb=bA@mail.gmail.com>
Date: Thu, 17 Jul 2025 20:13:54 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Gaowei Pu <pugaowei@...o.com>
Cc: rafael@...nel.org, viresh.kumar@...aro.org, linux-pm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] cpufreq: queue policy->update work to a dedicated thread

On Thu, Jul 17, 2025 at 10:51 AM Gaowei Pu <pugaowei@...o.com> wrote:
>
> We should ensure the low schedule latency of cpu frequency limits work
> to meet performance and power demands.

Why is the current arrangement insufficient?

> so queue the policy->update work to a dedicated thread.
>
> Remove the rt setting of the thread in patch v1 at Tim and
> Rafael J's request. However, it's will not meet everyone's request
> when we add a dedicated highpri workqueue to do the policy update work.

Why is it insufficient?

> Therefore, we keep the thread and will add a vendor hook in andorid aosp
> branch lately so we can customize the thread conveniently.

If you want to do something in the mainline kernel just for the
convenience of Android AOSP, with all due respect thereof, don't do
it.

This is not going to be considered for 6.17, so you may as well come
back with it when 6.17-rc1 is out.

Thanks!