Idle Power discussion

[marceloamaral]

In the recent refactoring PR #1089, I modified the logic to calculate power per-process and then aggregate the data per container, pod, and VM.

This change was made to support scenarios where we expose process and VM power, ensuring consistency across all scenarios using the same logic to estimate the power.

However, this change has significantly impacted the idle power logic. Previously, Kepler evenly distributed idle power among
all containers, regardless of the number of processes in the containers or kernel. With the new logic, idle power is evenly distributed among all processes. As a result, containers with more processes will have more associated idle power, and the kernel will also have more associated idle power…

This adjustment means that the idle power of containers differs in the new version of Kepler.

Following the GHG protocol, idle power for VMs should be divided based on VM size. However, at the process and container levels,
this division is challenging since they typically don't have resources hard allocated as in VMs (only resource limits which are not mandatory to be used). Thus, the basic assumption is that all processes are equal, and idle power is evenly distributed among them.

@rootfs @eilamt Any thoughts or concerns about this approach?

[marceloamaral]

@novacain1 ^^

[rootfs]

great summary @marceloamaral

Now we have more than one idle power attribution methods, it can be all possible that there could be more out there, since there is no well defined standard in this area.

For that challenge, let's come up with an idle power plugins and document different algorithms and and use cases, so that we can choose and switch algorithms over time till there is a winning algorithm or a standard in idle power.

In addition to the single distribution method, what about supporting both allocation based ratio and use base idle power ratio?

• The ratios based on the number of containers or processes work best if the resource allocated to the processes or containers are known. In many of our deployments, the pods are best effort, not guaranteed with resource allocation. So such ratio will lead to undesired results.
• The consumption based ratio, e.g. idle power are distributed to processes based on their actual consumption of resources (in our existing metrics, the cpu time or task clock, are good representation of how much time resources are being consumed).

[rootfs]

@marceloamaral Along the line of exposing idle power, we should also expose absolute power, that's the raw power reading before we calculate dynamic and idle power. For use cases that just want to use raw power readings, such metrics should be more helpful.

[marceloamaral]

Thanks @rootfs for the discussion!

From what I understood in the literature, the reason behind not splitting idle power based on resource utilization is because unlike dynamic power, idle power remains constant regardless of resource utilization. Therefore, they need to be handled differently.
We should think about the idle power as the power that is consumed just because the application exist, regardless of resource utilization.

That is, relying only on resource utilization to allocate idle power might not be the most "fair" approach. Resource utilization tends to fluctuate and may not always accurately reflect an application's size or resource requirements. Applications with similar resource utilization levels could have varying resource demands, leading to unequal contributions to idle power consumption. Consequently, solely using resource utilization for idle power allocation could result in disparities among applications, leading to inaccurate power consumption estimations and potentially biased resource management decisions.

Up to this point, my believe that evenly distributing idle power seems to be the most pragmatic approach, especially without detailed knowledge of each application's resource allocation.

Now, the question is: should we base the splitting of idle power on processes or containers? Opting for processes might imply that
the size of application will be determined by the number of process, and than the OS could have a higher proportion of idle power. But maybe this is ok. Btw, splitting the idle power by processes is the simplest way to support all the use cases where we expose power for processes.