Re: [PATCH 1/2] sched/fair: Reset incompatible burst on quota change

["Michal Koutný" <mkoutny@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

On Thu, Aug 20, 2026 at 11:32:17AM +0800, Zhe Liu <liuzhe1@kylinos.cn> wrote:
> A burst configured while a cgroup has unlimited CPU bandwidth can prevent
> a later finite quota from being installed.  For example, on cgroup v2:
> 
>   # echo 100000000 > cpu.max.burst
>   # echo "50000 100000" > cpu.max
>   sh: write error: Invalid argument
> 
> The quota remains unlimited because tg_set_bandwidth() validates the
> existing burst against the new quota.  Recovering requires userspace to
> know that it must clear the burst before retrying the quota update.  The
> same problem affects cpu.cfs_quota_us on cgroup v1.
> 
> When changing the quota, reset the existing burst to zero if it is
> incompatible with a valid finite quota.  Preserve it when it remains
> compatible or when the new quota is unlimited.  This lets a quota update
> take effect without depending on the order in which userspace writes the
> two files.
> 
> Rejecting the quota would retain this ordering dependency.  Clamping the
> burst would instead silently choose a different nonzero policy on behalf
> of userspace.

Why not clamp the burst_us to quota_us? That's quite natural to me.

> Resetting it to zero provides the existing no-burst default while
> leaving compatible bursts untouched.

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,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]