Feature request for enabling turbo boost and setting CPU min/max frequency

[kashifest]

Hi,

I would like request two new features in kubernetes-power-manager

enable/disable Turbo Boost Technology

Allow enabling and disabling Turbo boost technology through a flag so that the user can dictate if turbo boost technology should be enabled or not

Setting min/max frequency

Allow setting minimum and maximum CPU frequency so that users can set it accordingly. This way user can dictate the minimum and maximum CPU frequencies for different CPUs.

Let me know how you feel about these and I am ready to implementing it once we decide.

[adorney99]

Hi @kashifest, thanks for these suggestions.

enable/disable Turbo Boost Technology

Just have a couple questions on how this feature would work:

• What kind of systems (os, linux kernel version, CPU) would you be using this feature on? If we were to work on this we'd like to replicate a setup that has a use case for the feature just for validation. Something to note is that systems using a feature like this would need to have a somewhat up to date kernel to enable turbo boost through sysfs as I believe older versions of turbo boost could only be enabled/disabled through BIOS.
• Would the use case for this feature be to enable/disable turbo boost on all systems using power manager during the managers' startup? The reason I ask is because enabling/disabling the feature only on certain nodes or enabling/disabling the feature on the fly after deployment would be more complex to implement.

Setting min/max frequency

If I'm understanding correctly this feature already exists in the manager. Users can define custom power profiles that allow them to define their own frequency ranges like so:

apiVersion: power.intel.com/v1
kind: PowerProfile
metadata:
  name: custom
  namespace: intel-power
spec:
  name: "custom"
  max: 6100
  min: 5700
  epp: "performance"

The custom profile can then be requested in a pod spec using its name like so

power.intel.com/custom: "2"

[gschatz]

@kashifest , can you comment on the desired timeline for the requested features? Any specific end-customers you can share? Asking for planning and prioritization vs. other requirements. Thank you.

[kashifest]

Thanks a lot for the prompt replies. I will get back soon. @adorney99 @gschatz

[kashifest]

• What kind of systems (os, linux kernel version, CPU) would you be using this feature on? If we were to work on this we'd like to replicate a setup that has a use case for the feature just for validation. Something to note is that systems using a feature like this would need to have a somewhat up to date kernel to enable turbo boost through sysfs as I believe older versions of turbo boost could only be enabled/disabled through BIOS.

We are using SLES 15 SP5 with kernel 5.14 and using Intel CPU(s) ice lake, SPR etc . We are working with new hardware where the sysfs way of enable / disable works for turbo boost.

• Would the use case for this feature be to enable/disable turbo boost on all systems using power manager during the managers' startup?

Our ambition is to enable / disable the feature on a need basis and not some thing that needs to be decided when the server is configured. So we want to move away from BIOS and make it configurable via OS and then alter the config on a need basis. We can make it work it similar to C state configuration where there is a profile and we set turbo enable / disable and then the profile can be bound to certain servers and that should do the trick.

@kashifest , can you comment on the desired timeline for the requested features? Any specific end-customers you can share? Asking for planning and prioritization vs. other requirements. Thank you.

This is not for specific end customers but is an overall configuration that will be used for different deployments including 5G deployments. When it comes to timeline, we want this feature in Q3 2024 if possible and we are also ready to contribute to the project and make the patches etc. So we could collaborate and work together on this.

[kashifest]

Setting min/max frequency

If I'm understanding correctly this feature already exists in the manager. Users can define custom power profiles that allow them to define their own frequency ranges like so:

apiVersion: power.intel.com/v1
kind: PowerProfile
metadata:
  name: custom
  namespace: intel-power
spec:
  name: "custom"
  max: 6100
  min: 5700
  epp: "performance"

The custom profile can then be requested in a pod spec using its name like so

power.intel.com/custom: "2"

The idea is not to tie it to any workload but rather set it on a node level as you do for c-states for example here

[kashifest]

@adorney99 @gschatz any thoughts on the answers ?

[adorney99]

Hi @kashifest, really sorry for the late response but we've been discussing the turbo boost feature request and trying to do some planning around the feature in the background. Don't have any updates on that just yet but I had just a couple questions on the second feature request so I can properly generate stories for both features.

By setting frequency on a node level do you mean setting a frequency range on all cores on the node, setting it on a specific set of cores or something more application specific? Here's a couple features we have that might already overlap with what you're looking for.

specific cores

If you're looking to set the frequency range on a set of specific cores we recently added the ability to set the frequency on reserved cores. These are cores that won't be allocated by kubernetes to a pod.

all cores on the node

The shared pool lets you set a specific frequency on all cores on the node apart from the reserved cores (if you want you could also configure the reserved cores to have the same range though). Any pods that don't explicitly request a profile will operate at this frequency.

Sorry again for the late response

[kashifest]

Hi @adorney99 the following is what matches to our expectations from your suggestions:

all cores on the node

The shared pool lets you set a specific frequency on all cores on the node apart from the reserved cores (if you want you could also configure the reserved cores to have the same range though). Any pods that don't explicitly request a profile will operate at this frequency.

[kashifest]

Hi @adorney99 any updates on this? It would be really helpful if you can share the timeline and the plan for this? As I mentioned before, we can also help with the implementation if needed.

[kashifest]

@adorney99 @gschatz I am a bit lost about the timeline for this issue, do you need anymore information or is there any other forum where we need to discuss about how to proceed with this?

[chrismcn]

Hi Kashifest, we have been working on a plan forward with this request and are expecting to accommodate the changes. Pls have a chat with Ganesh at your convenience as he has additional details.