From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D410F3BD224 for ; Thu, 28 May 2026 14:37:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779979040; cv=none; b=KEi1RVSSLNkx3QM+6yAbIqLz7mB/W5chD1UL8pPfm/Gq6OO2Dnkc/GyqjMKI3uW6uQt+V9WPEErs+vlQeOCnB1lwxb4bh285bTmtTS7CK4I/+x+K+ECgOAK4gO2eY1+UolXe5njounUPnANrDW6/9LPbggHRMkRKXTCI2pzzq3g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779979040; c=relaxed/simple; bh=2nJHAeVElJ0iq9tJYkbPGTgBaa6MgSWZIAiL1mi6Pv4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eq6s60Dxv8szSW7lbraXDxPkbI476YayIkSYuFos7lO85gBXAasOuSaThyE/g3fw+lbKbjkYYCxeb9iVYeSmk81Ibun73vYSxbfOKqXWcWlQYSJ6e07nl9wJsw9Os5tmv3jo2hNu3kt/8RHnjbrC0SUOYETiiFPmgteRgAuaIa0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hMjWpWMj; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hMjWpWMj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 556DA1F000E9; Thu, 28 May 2026 14:37:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779979039; bh=P0W+Uj+Vb/svuGH0UZoxESdFqbjWOTq0PXcytALnchw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=hMjWpWMjGDArhm6RJvwkS3PvIuEG83KS97X9tjw7tulXwL5IrKAAcp92Bm9pbLPRH ejC92SYyXUJ0Buy4ZiGJLzPgMVZjjW2kJtHF9jO0NPm0EU7MIDPpdJOgoMMdZ5Agl0 5ByR+Ce1ElLAPiaAKWB++5P4WfIQb1fQ+4u8SlihOL4kmsbR2ASnNgboPkdrh7hY4E lDfS6x9rWcQqpOhTG9fydzpRxPGkpXqVTEWuRfjNE83decU+EEZd5OmxroT7U3nTws XlsV89TxFfW8f59aI+IOH69Yn5BYVPyiD7H0cppcZbICv/eM/O93Gx8UTZS2Nu7yC8 Q9e8ilE6d9hGA== Date: Thu, 28 May 2026 04:37:18 -1000 From: Tejun Heo To: Fernand Sieber Cc: arighi@nvidia.com, bsegall@google.com, changwoo@igalia.com, dietmar.eggemann@arm.com, dwmw@amazon.co.uk, fmubeen@amazon.de, hborghor@amazon.de, juri.lelli@redhat.com, linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com, nh-open-source@amazon.com, peterz@infradead.org, vincent.guittot@linaro.org, void@manifault.com Subject: Re: [PATCH 1/2] sched/fair: expose cpu.max.runtime to set bandwidth runtime directly Message-ID: References: <20260528065428.69225-1-sieberf@amazon.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260528065428.69225-1-sieberf@amazon.com> Hello, On Thu, May 28, 2026 at 08:54:28AM +0200, Fernand Sieber wrote: > Hi Tejun, > > On Wed, May 27, 2026 at 09:04:37AM -1000, Tejun Heo wrote: > > On Mon, May 25, 2026 at 09:36:21PM +0200, Fernand Sieber wrote: > > > Add a cpu.max.runtime cgroup v2 interface that allows userspace to > > > set the CFS bandwidth controller's runtime directly. This enables > > > CPU credit injection: an orchestrator writes a runtime budget which > > > the cgroup consumes naturally through the existing bandwidth > > > enforcement mechanism. > > > > Can you detail the use case? What problem is it solving how? > > Our use case is managing CPU credits for VMs. > > Product spec defines credits accumulation rate (quota), credits > limit (burst), and initial level of credits at launch (runtime). > > Controlling runtime is also necessary for preserving credits across > live update (kexec) and live migration. > > It is possible to approximate this behavior with existing kernel > primitives. However this requires setting up awkward parallel > accounting/control logic from userspace which must be periodically > synced up with the kernel. Instead, we propose minimal changes to > the cpu bw primitives to facilitate this use case. Can you please go into more details, preferably a lot more? From cgroup POV, there is a precedent for this sort of direct-ish low level control in memory.reclaim; however, as things like this can create a lot of implementation detail exposure, and I think the bar for use case justification should be pretty high - the use cases should make general sense and there are no other reasonable ways to achieve the same without adding the proposed interface. I don't think the above description achieves that. Thanks. -- tejun