nri icon indicating copy to clipboard operation
nri copied to clipboard

[Proposal] Add cgroups `burst` support

Open TonyxSun opened this issue 5 months ago • 5 comments

OCI runtime-specs had added support for the burst cgroups configuration (ref).

Propose to add support in NRI to allow greater range of container adjustments and updates.

Similarly, the cpu.idle parameter is not supported either and can be added.

Can work on this as a first issue.

TonyxSun avatar Jul 24 '25 22:07 TonyxSun

Similarly, the cpu.idle parameter is not supported either and can be added.

@TonyxSun Are you sure, the cpu.idle parameter cannot be adjusted/set using the cgroupv2 unified map parameter ?

klihub avatar Jul 25 '25 12:07 klihub

Thanks for pointing that out, didn't notice its existence. cpu.max.burst can similarly be set using the unified map, any benefit to having it be supported as a first class field? (only one i can think of is better support for cgroups v1).

Might be good to add mention of this in https://github.com/containerd/nri/blob/main/README.md?plain=1#L221?

TonyxSun avatar Jul 25 '25 15:07 TonyxSun

Thanks for pointing that out, didn't notice its existence. cpu.max.burst can similarly be set using the unified map, any benefit to having it be supported as a first class field? (only one i can think of is better support for cgroups v1).

Well, on the wire protocol there is no point in adding dedicated fields. But we could consider adding some reasonable coherent set of dedicated receiver functions for pkg/api.ContainerAdjustment, to allow a more natural way for setting v2 cpu.* controller fields than the 'unified' map (or the runc/crun v1-to-v2 conversion). If we decide to do so we have to be careful though, as it would introduce ambiguity by providing multiple ways for setting many of the cpu-related conteoller fields.

Might be good to add mention of this in https://github.com/containerd/nri/blob/main/README.md?plain=1#L221?

Definitely. And maybe an example in the form of a sample plugin...

klihub avatar Jul 28 '25 08:07 klihub

If we decide to do so we have to be careful though, as it would introduce ambiguity by providing multiple ways for setting many of the cpu-related conteoller fields.

It could be helpful to provide receiver fns for v2 fields with no v1 translation. Maybe we can revisit as needs come up.

One gap for my use case - I might need to support setting the cfs_burst_us v1 field. There isn't a way to do this right now, correct?

And maybe an example in the form of a sample plugin... Noted 👍🏼

TonyxSun avatar Jul 28 '25 21:07 TonyxSun

One gap for my use case - I might need to support setting the cfs_burst_us v1 field. There isn't a way to do this right now, correct?

Yes, I think there is no way to do that ATM, especially so if the OCI Spec does not support that v1 field (need to check, can't recall).

klihub avatar Jul 30 '25 12:07 klihub