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: <CAJZ5v0gpYQwC=1piaX-PNoyeoYJ7uw=DtAGdTVEXAsi4bnSdbA@mail.gmail.com>
Date: Mon, 15 Dec 2025 16:06:37 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Changwoo Min <changwoo@...lia.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, 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

On Mon, Dec 15, 2025 at 4:01 PM Changwoo Min <changwoo@...lia.com> wrote:
>
> 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?

I personally would be for something like "device-energy-model", where
"device" may mean any kind of device including CPU devices.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ