What Power Model should be applied to Kepler for each scenario?

[sunya-ch]

In this post, I would like to discuss about the Power Model to be used in the Kepler by default for different measurement and node information availability.
In the Kepler Model Server, I proposed to have 8 types of trained power models.
The detailed explanation about each type is here.
To simplify,

• Abs refers to Node-level and Dyn refers to Pod-level.
• Power refers to total power including non-ITPower and ComponentPower refers to core, dram.
• Weight refers to weight for Linear Regression which can be directly applied without extra library and without Weight refers to arbitrary model inference which requires kepler-estimator that comes with extra library.

Thus, we have 8 combinations of the above choices.

My idea is to apply each combinations of {Abs,Dyn} x {Power,ComponentPower} regarding the following scenarios.
Note that, the choice of with Weight and without Weight will be depend on model accuracy and inference overhead trade-off.
We may consider with Weight by default.

Scenario	Total Power (e.g., from ACPI)	RAPL	Environment Info (temperature)	Node HW Info. (arch., frequency)	Power Model (map to Pod)	Note
BM (x86 with power meter)	✔️	✔️			Pod Ratio Power Model	WIP
BM (non-x86 with power meter)	✔️	X		✔️	Node Component Power Model (AbsComponentPower) + Pod Ratio Power Model	WIP
BM (x86 but no power meter)	X	✔️	(:heavy_check_mark:)	✔️	Total Power Model (AbsPower) + Pod Ratio Power Model	WIP
BM (non-x86 and no power meter)	X	X	(:heavy_check_mark:)	✔️	Total Power Model (AbsPower) + Node Component Power Model (AbsComponentPower) + Pod Ratio Power Model	WIP
VM with power passthrough from BM (x86 with power meter)	✔️	✔️			VM Ratio Power Model + Pod Ratio Power Model	Future Work
VM with power passthrough from BM (non-x86 with power meter)	✔️	X		✔️	Node Component Power Model (AbsComponentPower) +VM Ratio Power Model + Pod Ratio Power Model	Future Work
VM with power passthrough from BM (x86)	X	✔️	(:heavy_check_mark:)	✔️	Total Power Model (AbsPower) +VM Ratio Power Model + Pod Ratio Power Model	Future Work
VM with Node Info.	X	X	(:heavy_check_mark:)	✔️	Total Power Model (AbsPower) +Node Component Power Model (AbsComponentPower) +VM Ratio Power Model + Pod Ratio Power Model	Future Work
Pure VM	X	X		X	Generalized Pod Model (DynPower + DynComponentPower)	WIP

remarks:

• ✔️ : available
• ✗ : not available
• empty : no concern

I put Environment Info in optional as it might be the future extension of Kepler to read this value. If it becomes available, it can be a feature to make AbsPower model more accurate.

The training process (pipelines) of each model type is listed in the below table.

Model	Training Input	Label Data
AbsPower	Total Usage + Node Info + (Environment Info)	Total Power
AbsComponentPower	Total Usage + Node Info	RAPL
DynPower	Pod Usage + AbsPower Model	Total Power
DynComponentPower	Pod Usage + AbsComponentPower Model	RAPL
DynPower	Pod Usage + Idle Power	Total Power
DynComponentPower	Pod Usage + Idle Component Powers	RAPL

This is basically all for my current thought. It would be great if I could have your opinions about this direction.

[rootfs]

@sustainable-computing-io/reviewer

[rootfs]

@sunya-ch can you add note to the symbols O and X? If my reading is right, the O and O case (top row) is good for VM, and O and X is good non x86 platforms?

[sunya-ch]

Sorry for misleading.
Basically, O means available, X means unavailable, and - means no need to concern. I will add that to the post.

The top row is the bare metal case where both total power (from energy meter) and RAPL of x86 platform are available.
The last row is more like cluster on Virtual Private Cloud.

[rootfs]

This looks great! With bare metal and pure VM, you have all use cases covered!

[marceloamaral]

For the sake of clarity, what about instead of we say

• AbsPower we say NodePower and specify the idle and dynamic part

  • NodePowerIdle
  • NodePowerDyn

• AbsComponentPower we say NodeComponentPower, but we specify the component

  • NodeSocketPowerIdle
  • NodeSocketPowerDyn
  • NodeDRAMPowerIdle
  • NodeDRAMPowerDyn
  • NodeOTHERPowerIdle (where other is =NodeTotal - Socket - DRAM)
  • NodeOTHERPowerDyn
  • NodePowerIdle (the sum of what is available)
  • NodePowerDyn

• DynPower we say PodDynPower, but we also define idle and components

  • PodSocketIdlePower
  • PodSocketDynPower
  • PodDRAMIdlePower
  • PodDRAMDynPower
  • PodOTHERIdlePower (where other is proportional to the NodeOTHER)
  • PodOTHERDynPower
  • PodPowerIdle (the sum of what is available/calculated)
  • PodPowerDyn

Some methods will not report some of these metrics, by listing that we can make it much more transparent

---

Additionally, we can define socket but some machines reports the RAPL cores, so that we can also have the CPU cores power
In the case that we have the core, we might have the socketOther which is all other socket components that are not the core....

---

Finally, we might have:

• Energy the aggregated energy consumed over a time
• Power the current energy consumption (=Energy/Interval)

I am planning to refactor the metrics and the code to reflect this logic of Energy and Power

[sunya-ch]

I agree that we should rename these Abs -> Node, Dyn -> Pod for the model server part.

• For the component, we don't need to add the prefix I think. We now have only core, pod but of course, we can change from core to socket because we are going to use the RAPL package as a single component not the core, right? I think instead of making too much variation right now. Let keep a specific set of component to report to Socket and DRAM (maybe adding GPU in the near future).
• The prediction model will not separate dynamic and idle part generally. But of course, we can define idle and dynamic inside the ratio function. Idle Power in the table means the stat value that we might collect it somehow (currently I used the Abs model to estimate it though). It will not the pod power model reported to the Kepler as it is used to only from removing the system-dependency part in training which can be applied to the other system.
• Actually, I have already separate Power (curr) and Energy (aggregated) in the reader. Not sure is there still mixing left.

[sunya-ch]

Here is the power model application flow logic I can think of right now.
What do you think?

flowchart TD;
   ACPI--installed-->NodeTotalPower=ACPI;
   NodeTotalPower=ACPI-->RAPL;
   ACPI--not installed-->NodeTotalPowerModel--available-->NodeTotalPower=NodeTotalPowerModel;
   NodeTotalPowerModel--not available-->NodeTotalPower=NodeComponentPowers;
   NodeTotalPower=NodeTotalPowerModel-->RAPL;
   NodeTotalPower=NodeComponentPowers-->RAPL;
   RAPL--support-->NodeComponentPowers=RAPL;
   RAPL--not support--> NodeComponentPowerModel;
   NodeComponentPowerModel--available-->NodeComponentPowers=NodeComponentPowerModel;
   NodeComponentPowers=RAPL-->PodPowerRatio;
   NodeComponentPowers=NodeComponentPowerModel-->PodPowerRatio;
   NodeComponentPowerModel--not available-->PodTotalPowerModel,PodComponentPowerModel;

Loading

Power values is composed of core, uncore, dram, gpu, others.
pkg = core + uncore
others = TotalPower - pkg - dram - gpu

If TotalPowerModel is not available, assume others = 0, TotalPower = ComponentPowerModel(pkg) + ComponentPowerModel(dram) + gpu.
If core is missing, assume uncore = 0, pkg= core.
If dram is missing, dram = 0
If ComponentPowerModel is not available, assume dram, uncore, other = 0, pkg = core = TotalPower.
If no PowerModel available < --- should not let this happen. we should at least provide initial weight for generalized PodComponentPowerModel.

[rootfs]

could you get this into a doc too? Love to have such a visual for understanding