mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Changwoo Min <changwoo@igalia.com>
To: Lukasz Luba <lukasz.luba@arm.com>
Cc: christian.loehle@arm.com, tj@kernel.org, pavel@kernel.org,
	len.brown@intel.com, rafael@kernel.org, kernel-dev@igalia.com,
	linux-pm@vger.kernel.org, sched-ext@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH v2 00/10] PM: EM: Add netlink support for the energy model.
Date: Wed, 2 Jul 2025 10:02:51 +0900	[thread overview]
Message-ID: <99c6cb28-3ab9-45a7-8bac-2598c0e2a59f@igalia.com> (raw)
In-Reply-To: <5afe2400-659d-40d8-ab4f-33a1b250ac85@arm.com>

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

      reply	other threads:[~2025-07-02  1:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-13  9:44 Changwoo Min
2025-06-13  9:44 ` [PATCH v2 01/10] PM: EM: Add em.yaml and autogen files Changwoo Min
2025-06-13  9:44 ` [PATCH v2 02/10] PM: EM: Add a skeleton code for netlink notification Changwoo Min
2025-06-13  9:44 ` [PATCH v2 03/10] PM: EM: Assign a unique ID when creating a performance domain Changwoo Min
2025-06-13  9:44 ` [PATCH v2 04/10] PM: EM: Expose the ID of a performance domain via debugfs Changwoo Min
2025-06-13  9:44 ` [PATCH v2 05/10] PM: EM: Add an iterator and accessor for the performance domain Changwoo Min
2025-06-13  9:44 ` [PATCH v2 06/10] PM: EM: Implement em_nl_get_pds_doit() Changwoo Min
2025-06-13  9:44 ` [PATCH v2 07/10] PM: EM: Implement em_nl_get_pd_table_doit() Changwoo Min
2025-06-13  9:44 ` [PATCH v2 08/10] PM: EM: Implement em_notify_pd_deleted() Changwoo Min
2025-06-13  9:44 ` [PATCH v2 09/10] PM: EM: Implement em_notify_pd_created/updated() Changwoo Min
2025-06-13 20:02   ` kernel test robot
2025-06-13  9:44 ` [PATCH v2 10/10] PM: EM: Notify an event when the performance domain changes Changwoo Min
2025-06-27  3:37 ` [PATCH v2 00/10] PM: EM: Add netlink support for the energy model Changwoo Min
2025-06-30 10:07   ` Lukasz Luba
2025-07-02  1:02     ` Changwoo Min [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99c6cb28-3ab9-45a7-8bac-2598c0e2a59f@igalia.com \
    --to=changwoo@igalia.com \
    --cc=christian.loehle@arm.com \
    --cc=kernel-dev@igalia.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=pavel@kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®