[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5a8b9d35-dedf-4129-8100-ce71d32a13ff@arm.com>
Date: Tue, 12 Nov 2024 09:21:12 +0100
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM <linux-pm@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Lukasz Luba <lukasz.luba@....com>,
Peter Zijlstra <peterz@...radead.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Len Brown <len.brown@...el.com>, Morten Rasmussen
<morten.rasmussen@....com>, Vincent Guittot <vincent.guittot@...aro.org>,
Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
Subject: Re: [RFC][PATCH v0.1 3/6] PM: EM: Add special case to
em_dev_register_perf_domain()
On 08/11/2024 17:38, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> Allow em_dev_register_perf_domain() to register a cost-only stub
> perf domain with one-element states table if the .active_power()
> callback is not provided.
>
> Subsequently, this will be used by the intel_pstate driver to register
> stub perf domains for CPUs on hybrid systems.
Looks like a 'stub' PD only distinguish itself from a normal PD by not
checking that all CPU in that PD have the same CPU capacity value?
I assume you do this since the Performance Cores (CPUs) can have
different CPU capacity values due to slightly different 'itmt prio' values?
So strictly speaking such a Intel hybrid machine would be tri-gear
system to fit the definition of a PD.
I thought initially by reading the word 'stub' that you only setup a
part of the default EM infrastructure.
[...]
Powered by blists - more mailing lists