Hi all,

This patch set adds new callback and support for artificial Energy Model (EM).
The new EMs have artificially generated performance states.
Such EMs can be created from lean information sources, such
as the relative energy efficiency between CPUs. The ACPI based
platforms provide this information
(ACPI 6.4, s5.2.12.14 'GIC CPU Interface (GICC) Structure'
'Processor Power efficiency Class' field).

Artificial EMs might require to directly provide the 'cost' of
the generated performance state. This patch set adds a new callback
.get_cost() for this. The EM framework does not force any model
or formula, it's up to the platform code.

Artificial EMs aim to leverage the Energy Aware Scheduler
(EAS). Other frameworks relying on performance states
information (i.e. IPA/DTPM) must be informed of the
EM type and might be prevented from using it. This patch
sets also does this by introducing a new flag:
EM_PERF_DOMAIN_ARTIFICIAL.

The patch set is based on current linux-next, where some
changes to OPP & EM are queuing.

The patch set also contains (patch 7/8 and patch 8/8) logic which prevents
two EM's client frameworks from using this new EM type. Some other approach,
using 'milli-watts', has been proposed and discussed, but refused [1].
This new flag is more precised and should not leave space for
wrong interpretation.

Shortly after this patch set you will see a patch set implementing the
platform code and registering this new EM.

Regards,
Lukasz Luba

[1] https://lore.kernel.org/linux-pm/20220207073036.14901-1-lukasz.luba@arm.com/

Lukasz Luba (7):
  PM: EM: Add .get_cost() callback
  PM: EM: Use the new .get_cost() callback while registering EM
  PM: EM: Change the order of arguments in the .active_power() callback
  PM: EM: Remove old debugfs files and print all 'flags'
  Documentation: EM: Add artificial EM registration description
  thermal: cooling: Check Energy Model type in cpufreq_cooling and
    devfreq_cooling
  powercap: DTPM: Check for Energy Model type

Pierre Gondois (1):
  PM: EM: Add artificial EM flag

 Documentation/power/energy-model.rst  | 24 +++++++++-
 drivers/cpufreq/mediatek-cpufreq-hw.c |  4 +-
 drivers/cpufreq/scmi-cpufreq.c        |  4 +-
 drivers/opp/of.c                      |  6 +--
 drivers/powercap/dtpm_cpu.c           |  2 +-
 drivers/thermal/cpufreq_cooling.c     |  2 +-
 drivers/thermal/devfreq_cooling.c     |  8 ++--
 include/linux/energy_model.h          | 35 +++++++++++++--
 kernel/power/energy_model.c           | 63 +++++++++++++++------------
 9 files changed, 101 insertions(+), 47 deletions(-)

-- 
2.17.1

Hi Rafael,


The patch set has been on LKML for quite a while and got one ACK,
for the code touching something outside the EM (thermal cooling).

AFAICS there is no interest and objections from others for this code.

Therefore, I have a question:
What would be be process to have merge this code?
(We had internally a few reviews of this code)

On 3/21/22 09:57, Lukasz Luba wrote:
> Hi all,
> 
> This patch set adds new callback and support for artificial Energy Model (EM).
> The new EMs have artificially generated performance states.
> Such EMs can be created from lean information sources, such
> as the relative energy efficiency between CPUs. The ACPI based
> platforms provide this information
> (ACPI 6.4, s5.2.12.14 'GIC CPU Interface (GICC) Structure'
> 'Processor Power efficiency Class' field).
> 
> Artificial EMs might require to directly provide the 'cost' of
> the generated performance state. This patch set adds a new callback
> .get_cost() for this. The EM framework does not force any model
> or formula, it's up to the platform code.
> 
> Artificial EMs aim to leverage the Energy Aware Scheduler
> (EAS). Other frameworks relying on performance states
> information (i.e. IPA/DTPM) must be informed of the
> EM type and might be prevented from using it. This patch
> sets also does this by introducing a new flag:
> EM_PERF_DOMAIN_ARTIFICIAL.
> 
> The patch set is based on current linux-next, where some
> changes to OPP & EM are queuing.
> 
> The patch set also contains (patch 7/8 and patch 8/8) logic which prevents
> two EM's client frameworks from using this new EM type. Some other approach,
> using 'milli-watts', has been proposed and discussed, but refused [1].
> This new flag is more precised and should not leave space for
> wrong interpretation.
> 
> Shortly after this patch set you will see a patch set implementing the
> platform code and registering this new EM.
> 


No one from Arm is an official maintainer of the EM code.

Regards,
Lukasz

Hi Rafael,

gentle ping. If you need some help with this maintenance,
we can help.

Regards,
Lukasz

On 4/4/22 13:35, Lukasz Luba wrote:
> Hi Rafael,
> 
> 
> The patch set has been on LKML for quite a while and got one ACK,
> for the code touching something outside the EM (thermal cooling).
> 
> AFAICS there is no interest and objections from others for this code.
> 
> Therefore, I have a question:
> What would be be process to have merge this code?
> (We had internally a few reviews of this code)
> 
> On 3/21/22 09:57, Lukasz Luba wrote:
>> Hi all,
>>
>> This patch set adds new callback and support for artificial Energy 
>> Model (EM).
>> The new EMs have artificially generated performance states.
>> Such EMs can be created from lean information sources, such
>> as the relative energy efficiency between CPUs. The ACPI based
>> platforms provide this information
>> (ACPI 6.4, s5.2.12.14 'GIC CPU Interface (GICC) Structure'
>> 'Processor Power efficiency Class' field).
>>
>> Artificial EMs might require to directly provide the 'cost' of
>> the generated performance state. This patch set adds a new callback
>> .get_cost() for this. The EM framework does not force any model
>> or formula, it's up to the platform code.
>>
>> Artificial EMs aim to leverage the Energy Aware Scheduler
>> (EAS). Other frameworks relying on performance states
>> information (i.e. IPA/DTPM) must be informed of the
>> EM type and might be prevented from using it. This patch
>> sets also does this by introducing a new flag:
>> EM_PERF_DOMAIN_ARTIFICIAL.
>>
>> The patch set is based on current linux-next, where some
>> changes to OPP & EM are queuing.
>>
>> The patch set also contains (patch 7/8 and patch 8/8) logic which 
>> prevents
>> two EM's client frameworks from using this new EM type. Some other 
>> approach,
>> using 'milli-watts', has been proposed and discussed, but refused [1].
>> This new flag is more precised and should not leave space for
>> wrong interpretation.
>>
>> Shortly after this patch set you will see a patch set implementing the
>> platform code and registering this new EM.
>>
> 
> 
> No one from Arm is an official maintainer of the EM code.
> 
> Regards,
> Lukasz

Hi,

On Tue, Apr 12, 2022 at 8:53 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Hi Rafael,
>
> gentle ping. If you need some help with this maintenance,
> we can help.

Sorry for the delay.

Given the lack of objections or concerns, I've applied the whole
series as 5.19 material.

Thanks!

On 4/13/22 15:29, Rafael J. Wysocki wrote:
> Hi,
> 
> On Tue, Apr 12, 2022 at 8:53 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>> Hi Rafael,
>>
>> gentle ping. If you need some help with this maintenance,
>> we can help.
> 
> Sorry for the delay.
> 
> Given the lack of objections or concerns, I've applied the whole
> series as 5.19 material.

Thank you Rafael!

> 
> Thanks!