linux-kernel - Re: [PATCH v2 00/10] PM: EM: Add netlink support for the energy model.

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: <99c6cb28-3ab9-45a7-8bac-2598c0e2a59f@igalia.com>
Date: Wed, 2 Jul 2025 10:02:51 +0900
From: Changwoo Min <changwoo@...lia.com>
To: Lukasz Luba <lukasz.luba@....com>
Cc: christian.loehle@....com, tj@...nel.org, pavel@...nel.org,
 len.brown@...el.com, rafael@...nel.org, kernel-dev@...lia.com,
 linux-pm@...r.kernel.org, sched-ext@...ts.linux.dev,
 linux-kernel@...r.kernel.org, "Rafael J. Wysocki"
 <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH v2 00/10] PM: EM: Add netlink support for the energy
 model.

Hi Lukasz,

On 6/30/25 19:07, Lukasz Luba wrote:
>> @Lukasz, @Rafael -- I have a question related to the energy model
>> in general. As far as I understand, the energy model describes
>> the performance-energy consumption tradeoff when a single CPU in
>> a performance domain is running. However, in reality, SoCs may
>> have thermal constraints, which would result in additional
>> constraints. For example, running all CPUs with the highest
>> frequency may not be possible. My question is this: does kernel
>> maintain and use such (thermal?) constraints?
> 
> That's true in real scenarios on mobile SoCs, running with max freq
> on all CPUs is possible likely only for short period...
> 
> The Energy Model itself doesn't handle such situation. The code in
> thermal framework and in Energy Aware Scheduler has feature to handle
> it and know which top OPPs are not possible to be used.
> 
> Although, the EM in such situation is likely to be adjusted, because the
> SoC temperature reaches high values. Especially if that heat was
> generated by the GPU not CPUs themselves, then it's extra leakage will
> be accounted and EM data modified in runtime.
> 
> Another scenario when the EM might be updated is when Middleware
> will recognize a known 'scenario' e.g. long video conference
> with camera in use (thus Image Signal Processor, which also can
> heat the SoC, like GPU). Or a 'preferred profile' for light-weight
> application using some HW decoding, e.g. video playback and
> thus some CPUs are more preferred by EAS to be used in it (EM might
> change the energy efficiency gently for such CPUs).

Thank you for the explanation! Besides this, do you see anything that
needs to be addressed in the code? Of course, I expect there are. For
the one reported by the kernel test report, that is the obvious one, so
I will address it together with your and others' feedback

Regards,
Changwoo Min