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] [day] [month] [year] [list]

Message-ID: <a12b4548-dd21-43bb-bc62-18512fb93a6c@oppo.com>
Date: Fri, 18 Jul 2025 15:32:39 +0800
From: Gaowei Pu <pugaowei@...o.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: 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

Hi Rafael J,

On 2025/7/18 2:13, Rafael J. Wysocki wrote:
> 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?

Sorry, mabye i didn't make it clear. There are lots of critical tasks with higher
schedule priority than normal cfs tasks because they are related to drawing in android
systems(e.g., mvp tasks on Qualcomm, vip tasks on Mediatek).

The problem we met is that these critical tasks preempt the kworker doing the 'cpufreq policy->update' work
and delay the cpufreq update work for about 10ms. We can't boost the kworker beacause it's a common worker
thread which also doing other works. Therefore, queue the 'cpufreq policy->update' work to a dedicated thread
and customize the thread is a proper way we can do, not just for convenient.

> 
>> 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.

Okay, Should i try to pick this patch to Android AOSP branch? thanks.

> 
> 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!