Alpha version feature discussion

[ribalba]

It is important, that we get a first version up and running with a minimal set of features as soon as possible and then iterate on this version. So for the first version I propose a very minimal set of features. This is also down to that I think that there are loads of rabbit holes we could go down. Following points are important IMHO:

• We should use the same formula that Apple uses in their energy impact. A perfect splitting of the energy values is never possible and if we go with the way MacOS does it we have a first starting point and avoid endless discussions on how this could be done better. With energy impact there are loads of edge cases where the value does not correlate with actual energy usage but in most cases it does somehow reflect energy usage. So I see no reason why we shouldn't use the same formula. Even if we might change it in the future.
• Talking about Joules or Watts is very specific and if we will have to resort to power models instead of actual measurements it will never be exact. Apple resorted to calling the output value energy impact, we should find another wording but leave the option for maybe resorting to a stable, but non physical, wording, rather than shooting for physical but less stable. If it is possible to create stable physical values it should be preferred. This is to be picked up once we have both variants comparable in place.
• Kepler has already done amazing work for the Kubernetes world. I think we should see how they have implemented the ebpf part and see if we can reuse some of their code.
• As soon as we have the formula for energy impact and understand the ebpf part of Kepler it should be fairly simple to plug everything together
• One bit problem with Kepler is, that it suffered with many overhead issues in the past with the current status for us unclear. So we need to create a benchmark that measures the overhead of our code as in our case for potentially non-beefy machines the overhead is a key design criteria. Ideally this should be validate every time we release a new version directly in the tests.

(Edited by @ArneTR for links and clarity 30.05.2024)

[ArneTR]

Some more ideas for separate tasks we can work on in parallel that we have to tackle:

• Identify ways of putting energy values in existing cgroups. Idea is to have the values alongside something like cpu.stat or find alternatives by creating new cgroups and having a energy.stat / cpu.energy cgroup or similar.
• How does the system behave in realtime mode or when a different _SC_CLK_TCK is configured in terms of overhead and accuracy
• Identify all locations in the kernel where we can hook into via eBPF to get scheduling switches and / or cgroup writing.
• Identify all locations in the kernel where we can hook into via a kernel module to get scheduling switches and / or cgroup writing.