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] [thread-next>] [day] [month] [year] [list]
Message-ID: <d5b50da2-bc1f-4138-9733-218688bc1838@igalia.com>
Date: Tue, 16 Dec 2025 00:01:25 +0900
From: Changwoo Min <changwoo@...lia.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>, Donald Hunter <donald.hunter@...il.com>,
 Lukasz Luba <lukasz.luba@....com>, linux-pm@...r.kernel.org,
 sched-ext@...ts.linux.dev, Jakub Kicinski <kuba@...nel.org>,
 Network Development <netdev@...r.kernel.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Concerns with em.yaml YNL spec

Thanks, Rafael, for the comments.

On 12/15/25 19:30, Rafael J. Wysocki wrote:
> On Mon, Dec 15, 2025 at 2:57 AM Changwoo Min <changwoo@...lia.com> wrote:
>>
>> Hi  Andrew,
>>
>> On 12/15/25 01:21, Andrew Lunn wrote:
>>>>> We also need to watch out for other meaning of these letters. In the
>>>>> context of networking and Power over Ethernet, PD means Powered
>>>>> Device. We generally don't need to enumerate the PD, we are more
>>>>> interested in the Power Sourcing Equipment, PSE.
>>>>>
>>>>> And a dumb question. What is an energy model? A PSE needs some level
>>>>> of energy model, it needs to know how much energy each PD can consume
>>>>> in order that it is not oversubscribed.Is the energy model generic
>>>>> enough that it could be used for this? Or should this energy model get
>>>>> a prefix to limit its scope to a performance domain? The suggested
>>>>> name of this file would then become something like
>>>>> performance-domain-energy-model.yml?
>>>>>
>>>>
>>>> Lukasz might be the right person for this question. In my view, the
>>>> energy model essentially provides the performance-versus-power-
>>>> consumption curve for each performance domain.
>>>
>>> The problem here is, you are too narrowly focused. My introduction
>>> said:
>>>
>>>>> In the context of networking and Power over Ethernet, PD means
>>>>> Powered Device.
>>>
>>> You have not given any context. Reading the rest of your email, it
>>> sounds like you are talking about the energy model/performance domain
>>> for a collection of CPU cores?
>>>
>>> Now think about Linux as a whole, not the little corner you are
>>> interested in. Are there energy models anywhere else in Linux? What
>>> about the GPU cores? What about Linux regulators controlling power to
>>> peripherals? I pointed out the use case of Power over Ethernet needing
>>> an energy model.
>>>
>>>> Conceptually, the energy model covers the system-wide information; a
>>>> performance domain is information about one domain (e.g., big/medium/
>>>> little CPU blocks), so it is under the energy model; a performance state
>>>> is one dot in the performance-versus-power-consumption curve of a
>>>> performance domain.
>>>>
>>>> Since the energy model covers the system-wide information, energy-
>>>> model.yaml (as Donald suggested) sounds better to me.
>>>
>>> By system-wide, do you mean the whole of Linux? I could use it for
>>> GPUs, regulators, PoE? Is it sufficiently generic? I somehow doubt it
>>> is. So i think you need some sort of prefix to indicate the domain it
>>> is applicable to. We can then add GPU energy models, PoE energy
>>> models, etc by the side without getting into naming issues.
>>>
>>
>> This is really the question for the energy model maintainers. In my
>> understanding, the energy model can cover any device in the system,
>> including GPUs.
> 
> That's correct.
> 
>> But, in my limited experience, I haven’t seen such cases beyond CPUs.
>>
>> @Lukasz — What do you think? The focus here is on the scope of the
>> “energy model” and its proper naming in the NETLINK.
> 
> I think you need to frame your question more specifically.
> 

Let me provide the context of what has been discussed. Essentially, the
question is what the proper name of the netlink protocol is and its file
name for the energy model.

Donald raised concerns that “em” is too cryptic, so it should be
“energy-model”. The following is Donald’s comment:


   “- I think the spec could have been called energy-model.yaml and the
    family called "energy-model" instead of "em".”


Andrew’s opinion is that it would be appropriate to limit the scope of
“energy-model” by adding a prefix, for example, “performance-domain-
energy-model”. Andrew’s comment is as follows:

   “And a dumb question. What is an energy model? A PSE needs some level
   of energy model, it needs to know how much energy each PD can consume
   in order that it is not oversubscribed. Is the energy model generic
   enough that it could be used for this? Or should this energy model get
   a prefix to limit its scope to a performance domain? The suggested
   name of this file would then become something like
   performance-domain-energy-model.yml?”

For me, “performance-domain-energy-model” sounds weird because the
performance domain is conceptually under the energy model. If adding a
prefix to limit the scope, it should be something like “system-energy-
model”, and the “system” prefix looks redundant to me.

So, the question is what the proper name is for the energy model
protocol: “em”, “energy-model”, “performance-domain-energy-model”, or
something else?

Regards,
changwoo Min






Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ