runtime-spec
runtime-spec copied to clipboard
opencontainers
config-linux: add CFS bandwidth burst
Burstable CFS controller is introduced in Linux 5.14. This helps with parallel workloads that might be bursty. They can get throttled even when their average utilization is under quota. And they may be latency sensitive at the same time so that throttling them is undesired.
This feature borrows time now against the future underrun, at the cost
of increased interference against the other system users, by introducing
cfs_burst_us into CFS bandwidth control to enact the cap on unused
bandwidth accumulation, which will then used additionally for burst.
The patch adds the support/control for CFS bandwidth burst.
Fixes https://github.com/opencontainers/runtime-spec/issues/1119
Signed-off-by: Kailun Qin [email protected]
Dear spec maintainers @crosbymichael @cyphar @dqminh @giuseppe @hqhq @mrunalp @tianon @vbatts,
I received this feature request several times from runtime users of different orgnizations, would you please kindly take a look at this one so that we can move forward (also https://github.com/opencontainers/runc/pull/3205)?
Many thanks!
~~In my opinion, I think cpu_burst mode is a cgroupv2 only feature. Is there any compatibility issue if we change all schema that is used in both cgroupv1 and v2?~~
In my opinion, I think cpu_burst mode is a cgroupv2 only feature. Is there any compatibility issue if we change all schema that is used in both cgroupv1 and v2?
I see it is present with cgroup v1 too:
# ls /sys/fs/cgroup/cpu/cpu.cfs_burst_us
/sys/fs/cgroup/cpu/cpu.cfs_burst_us
If it was a cgroup v2 only feature then we could just use the unified map.
In my opinion, I think cpu_burst mode is a cgroupv2 only feature. Is there any compatibility issue if we change all schema that is used in both cgroupv1 and v2?
I see it is present with cgroup v1 too:
Yes, it supports both cgroup v1 and v2 IMO.
@Zheaoli Any special reason for considering it as cgroup v2 only?
Sorry for the bad information, my memory is wrong
I have confirmed the burst mode support both v1 and v2 since Linux 5.14, FYI https://www.kernel.org/doc/html/latest/scheduler/sched-bwc.html
~~But for this, maybe we should think about the kernel issue? The last LTS kernel is 5.10 which is not supported for burst mode(People may use 510 with the newest version of runc . Maybe we should make burst mode as an experimental feature before the Linux 5.15 has been released~~
But for this, maybe we should think about the kernel issue? The last LTS kernel is 5.10 which is not supported for burst mode(People may use 510 with the newest version of runc . Maybe we should make burst mode as an experimental feature before the Linux 5.15 has been released
The 5.15 kernel was released last year, and has already been marked as "LTS" for quite some time now. I do not understand why you are not using it now already :)
The 5.15 kernel was released last year, and has already been marked as "LTS" for quite some time now. I do not understand why you are not using it now already :)
Many of our machines are using 510 not 515, We can upgrade the runc version easier but it's a tough way to upgrade the kernel version(And my bad again, 515 has been released in 2021-10-31).
I think the spec is LGTM to me now.
For my personal idea, I'm very glad to see this spec will be accepted ASAP, because it's very useful for some performance-needed circumstances.
Perhaps it would help me (and other spec reviewers) if we level-set on how the feature works. Here's my current understanding -- is this accurate?
there's at most
quota+burstin any one givenperiod, and any use ofburstin aperiodcounts against a futureperiod's availablequota
Perhaps it would help me (and other spec reviewers) if we level-set on how the feature works. Here's my current understanding -- is this accurate?
there's at most
quota+burstin any one givenperiod, and any use ofburstin aperiodcounts against a futureperiod's availablequota
@tianon Please kindly take another look and see if it addresses the question. Thanks!
@tianon ping.
Hello guys, is there any blocking issue with this pull request?
LGTM, but please consider squashing commits
Squashed and rebased, PTAL, thanks!
Is there any chance to merge this PR in 2022?(A lot of people really need this(
There is two LGTM from the people who have the write access to this repo. Do we need more LGTM?