From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6DFB4398F5 for ; Thu, 20 Aug 2026 11:43:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787226208; cv=none; b=Pxo+6MdK2Zx7TTSqhD8FT0Ef5EfTOGmWMTtZ6ydUG84TKfJntIdee5+88ezbUHsl+NNTX0kZA+MIEc4fEhGeSp8kp7w78GTjBD8NPZgU8icoR7ktzTv4D6GC3eADCxCol0QjVrUHVCOQ/21rFiQeRLAXiHn1RFZORdjg4xFxb+A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787226208; c=relaxed/simple; bh=6Hy36tKqtpWDaWpvQ0XRRybVqYi3B32kl2Aie52EHHM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pADo3OinswZ6FfWtui03mzyuluE/PRzykOuzwu2kbiCoW2orokhGDEQ7fRAUDtQp5sKnJyYJOKBNxXHAYj4DD3PXQZAaQhUxr7EBqeZFMhNvRLeA2Xo8fQi72L4dMdUgu7pgfeII1xER7ZAkJ5X0Gm5tafjjtGBQfKtRqLPveg0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=TuPs/9lN; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="TuPs/9lN" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4953de5be0aso18054065e9.0 for ; Thu, 20 Aug 2026 04:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787226204; x=1787831004; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=9V5vN05xrZ88Pts7+MbgysCv3/LZ3VVMuZVNPdkuC9k=; b=TuPs/9lNAxnQECGWd7Q41+BTakiLJH9upC1PIfHpPDEIBBVDnHYueE4a9jTh+pIwo5 g3hJzb7Cbw1kDHYsGdbbIKg7XBjANoRbIZhcYqyT1Wbe62o2bK2DCbstQhvYB9iMzV8Y LfeKfQkViT//iipLEXXQ6y+P5idvGw4fSRNRZs6h5rUtsx5YDwyAOapmPcEq4+ZjM+/1 Tz5bigsjECWo9dYVWn8VrB7xSfba3u3C6XfyilDEk3rBkFs2cTET5yZ7qHkcif1Z4FpB TLC9JNsZRj/wxkBMI3Idv7JCgL7rXOOcIkNuEDqAJC7LXRyVhiRnHdgW/l6w9zS57ZRZ a7dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787226204; x=1787831004; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9V5vN05xrZ88Pts7+MbgysCv3/LZ3VVMuZVNPdkuC9k=; b=mJSCWa9gByNeFVBIhhkse9IUjezMlxf0r15fsdXMjFybMXdTKGtj2nV9bxAacXf+C3 trQUF+vC+UIwaSKkhpqsigE+A2hUT/Qp2TcNLFj/bbiry/3xRNCaHKtq2ZTM+Roy8Im7 IwYXDn6kjtLqWVis/54qy2hzsNVWS447VUa2y7ke+cvAsPoGjniGt3bO9zD2xaRqCCVe OhAMeoteiXori6HcChN9+8y1kczNsaMBW+yTnwskOZ13nrS0O5esX2eM1uufGDJhWXj+ jkGHuF8SnQ/ehHEzu0E2Kkmp8UAmjRBbu6gQLY+NiP5WUEkcnj6MlRY3SxKu14PW2WS2 c/6w== X-Forwarded-Encrypted: i=1; AHgh+Rqy/jJ+oDjW8cMIJjEhPY1OlXf3kVPxbd31XjREiK7GNEpLxhyFofB+3+qfUkvobKq00FXNxWxfMfj814o=@vger.kernel.org X-Gm-Message-State: AOJu0YxY1AeJJuCb3XcPbzMH0k/l99c94QF80+wIwYNKk/zSPrbvBi7f 2SD1z0h1QI5Fkd3pI6D54qnhziYlvsvoXYxKID3PqOpkyPXuEX5NmOeqUbJkWK2dxqM= X-Gm-Gg: AR+sD10AOgAIgmPkeRxGi3ygor66xRMwkO6tmXkGWMqzgoHYAwOPKtyEjCjpCKcsxlI F8mjXJN+ciApedTXY3Vzp1/yHiAr4OqYFhjDrLOhUDED0FqPLpdPWZVk7ukM/0/7+ScJaZO1Jmr lVPzmnLdAm4+ZjGlwYL9/JNi6Pzt4nv+E2ITPUJCIyEYpOUCGIPEc38E2QS8Kf5L66k3IQ4Wv2u IVqcB5RydoK2h5xcg5XMShJ6+uYTTEn1/Janvk3psO5PzmSsj8Mf7vKSGIvfpKvvpndAAt8Kaf2 P7FZgLyVJqUbIrJaj5l3UAKwzSxuH6nOgSKWGPIRoKPIa9ZlpTqSyvKtVzqmhW/6Oxdxb3BBpRa R2ROaWyaHYiNeVD3IkI0zU62O7QMj5VNqFPPrkP+ihJqosbEq7vqQ00zB4AS+ssHf7rYpGR8DXB GGeoWH6rcBHXRBUVxzIg+CJHUO14aniofn+6V1vepSJAAA/zeuUm8ChpxbSsNnRLM= X-Received: by 2002:a05:600c:468a:b0:496:c9cd:e7ab with SMTP id 5b1f17b1804b1-499aa172377mr164276785e9.5.1787226203746; Thu, 20 Aug 2026 04:43:23 -0700 (PDT) Received: from localhost.localdomain ([2001:af0:8000:1409:193:86:92:181]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499aa1111a7sm139337275e9.6.2026.08.20.04.43.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Aug 2026 04:43:23 -0700 (PDT) Date: Thu, 20 Aug 2026 13:43:21 +0200 From: Michal =?utf-8?Q?Koutn=C3=BD?= To: Zhe Liu Cc: tj@kernel.org, hannes@cmpxchg.org, corbet@lwn.net, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, skhan@linuxfoundation.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] sched/fair: Reset incompatible burst on quota change Message-ID: References: <20260820033218.214259-1-liuzhe1@kylinos.cn> <20260820033218.214259-2-liuzhe1@kylinos.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ljyugzshyqxvbva5" Content-Disposition: inline In-Reply-To: <20260820033218.214259-2-liuzhe1@kylinos.cn> --ljyugzshyqxvbva5 Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 1/2] sched/fair: Reset incompatible burst on quota change MIME-Version: 1.0 On Thu, Aug 20, 2026 at 11:32:17AM +0800, Zhe Liu wrot= e: > A burst configured while a cgroup has unlimited CPU bandwidth can prevent > a later finite quota from being installed. For example, on cgroup v2: >=20 > # echo 100000000 > cpu.max.burst > # echo "50000 100000" > cpu.max > sh: write error: Invalid argument >=20 > 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. >=20 > 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. >=20 > 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 --ljyugzshyqxvbva5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJEEABYKADkWIQRCE24Fn/AcRjnLivR+PQLnlNv4CAUCaoboVRsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDIACgkQfj0C55Tb+AjoWQD+Ih8SefrHPjy8wrrXINmL 1u5UhSH1rtRrBGNDUF32XLsA+gPkVJm6O80wMNqFk2Qzcn5wiQvR/pkjhJ9IU9G/ OksL =fx8D -----END PGP SIGNATURE----- --ljyugzshyqxvbva5--