On Thu, Aug 20, 2026 at 01:43:21PM +0200, Michal Koutný wrote:
> Why not clamp the burst_us to quota_us? That's quite natural to me.
>
> Like Sashiko said, the user configured values should not get lost, the
> resulting burst value (0 or quota or whatever makes sense) might be
> applied effectively (to allow configuration order independence) but not
> overwrite what was configured.
Thanks for the suggestion. I agree that applying the clamp at enforcement
time is a better fit here.
There is also a second ordering case to consider: when both quota and burst
are being increased, writing burst first currently fails with EINVAL because
the burst value is checked against the old quota.
For v2, I plan to remove the validation which couples burst_us to the
current quota_us. The quota upper-bound check will remain unchanged, while
burst_us will be checked independently against max_bw_runtime_us:
@@ tg_set_bandwidth()
if (quota_us != RUNTIME_INF &&/path/to/YOUR_REPLY
quota_us > max_bw_runtime_us)
return -EINVAL;
- if (quota_us != RUNTIME_INF && (burst_us > quota_us ||
- burst_us + quota_us >
max_bw_runtime_us))
+ if (burst_us > max_bw_runtime_us)
return -EINVAL;
The configured burst value will be retained, and the value used by CFS will
be capped when the runtime is refilled:
@@ __refill_cfs_bandwidth_runtime()
- cfs_b->runtime = min(cfs_b->runtime,
- cfs_b->quota + cfs_b->burst);
+ cfs_b->runtime = min(cfs_b->runtime,
+ cfs_b->quota +
+ min(cfs_b->burst, cfs_b->quota));
This preserves the value configured through cpu.max.burst and
cpu.cfs_burst_us while applying the clamp to the value used for enforcement.
It also allows the quota and burst settings to be written in either order.
I have tested both write-order sequences on linux-next next-20260824. A v2
with the corresponding selftest update will follow.
Thanks again for pointing this out.
