[msarnowicz]

This is a very valid scenario, however, one that is not yet fully baked into this implementation. But, as mentioned, this is a starting point. We want to hear feedback and see customers' workloads on Burstables first.

The main challenge here is that cpu.max.burst can be set no higher than the limit set in cpu.max. This limits our options to some extent. But we can still look at some possible implementation choices here: - Pack more VMs into the same slice/group, and with that lower the minimum CPU guaranteed, and at the same time lower the price point. This would increase the chance of running into a "noisy neighbor", but we expect it would not be used for any critical workload. - Implement calculation of CPU credits outside of the kernel and change the CPU max and burst limits dynamically over an extended period of time (hours and days, instead of sub-second).

[nighthawk454]

Gotcha, thanks for the reply. Makes sense to target burstables first - that seems to be the most common feature set. That’s interesting that it’s not readily available in the kernel. I once spoke to some AWS folks dealing with Batch/ECS scheduling of docker container tasks and they hit similar limitations. As a result their CPU max/burst settings work like the underlying cgroups too.

I imagine writing a custom scheduler would be quite an undertaking!

[msarnowicz]

I think so, too!