linux-kernel - Re: [PATCH] cpufreq: queue policy->update work to rt thread to reduce its schedule latency

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: <8f1585ed-06df-400b-b0d4-c0091d980cd4@oppo.com>
Date: Fri, 30 Aug 2024 17:44:59 +0800
From: Gaowei Pu <pugaowei@...o.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Tim Chen <tim.c.chen@...ux.intel.com>, viresh.kumar@...aro.org,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: queue policy->update work to rt thread to reduce
 its schedule latency


Hi Rafael J,

On 2024/8/27 1:48, Rafael J. Wysocki wrote:
> On Mon, Jul 22, 2024 at 4:30 AM Gaowei Pu <pugaowei@...o.com> wrote:
>>
>> Hi Tim,
>>
>> On 2024/7/19 6:03, Tim Chen wrote:
>>> On Wed, 2024-07-17 at 14:33 +0800, Gaowei Pu wrote:
>>>> Currently we encountered a problem that the cpufreq boost latency
>>>> is about 10 milliseconds or worse when we boost through cpufreq QOS request
>>>> under high workload scenarios, while the boost latency mainly consumed by
>>>> schedule latency of policy->update work.
>>>
>>> What is the tail latency now after your change?
>>>
>>>>
>>>> We should ensure the low schedule latency of cpu frequency limits work
>>>> to meet performance and power demands. so queue the policy->update work
>>>> to rt thread to reduce its schedule latency.
>>>
>>> If my understanding is correct, kthread has a default nice
>>> value of 0 and is not a rt thread.
>>>
>>> I think the gain you see is
>>> your patch created a dedicated kthread work queue on CPU 0.
>>> The work from policy change no longer have to compete time with other
>>> requests coming from schedule_work().
>>
>> It's not just other requests coming from schedule_work(), also some normal
>> cfs tasks running on the same cpu.
> 
> Do you have any data to support this statement?
Yes, i have some systraces in high workload android scenarios. 

will send to you if needed.

> 
>> In order to not competing time with the above threads, i change the thread
>> policy to rt and prio set to 98 to reduce the schedule latency.
> 
> By how much?

the tail latency now is about within 50 microseconds after my change.

> 
>>>
>>> If the policy change really needs to get ahead
>>> of other tasks, I think you need a dedicated
>>> workqueue with alloc_workqueue() using WQ_HIGHPRI flag.
>>
>> I think the cpufreq boost or limit action should be trigger in time to meet
>> performance and power demands. An dedicated workqueue with highpri will be
>> better but maybe not good enough because cfs pick or preempt policy is not
>> purely based on thread nice value. So i think the final solution is rt thread
>> and the policy change work deserves it :)
> 
> The "I think" and "maybe" in the above paragraph are not particularly
> convincing.
> 
> Switching it over to use a dedicated workqueue would be a no-brainer
> as using dedicated workqueues is recommended anyway and if it
> measurably improves performance, that's for the better.

Ok, thanks for your and Tim's advice. 

I used the dedicated workqueue with highpri(tested and the sched latency is within 1ms) 
to replace the rt thread and will send v2 later.

> 
> However, making it use a worker thread the way this patch does
> requires quite a clear demonstration that the above is not sufficient.
> 
> Thanks!