From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 504FD3469E7 for ; Thu, 7 May 2026 07:01:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778137278; cv=none; b=oNwnVLw/Lr0MD35UqPUecgZlqXZZAoYbM+PK7jjcFUFc44nFUwYgk+xwY/zZjOIWL4CLmUyQ7zB/SN3j/4X4e7PSbN3AH8kq4gM3YEHbmj05YBe1O3i3KFJ4TNtmE1Km/Vhp4bskEt92Vxcb3Z/GRCFbgM5Fga0xb+pV5DfyfkU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778137278; c=relaxed/simple; bh=Vpj4enGBsPMJqRM0KlHwjD7wxMiDObqGZ4rqHdPatZs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cVNtQ4u0DAVsPaGn4Ky6LmVx/aVSQMVD2rWBwgyhdbZOYeXo2b9L+u3F47Onx5JpRvnuP5zKLDIYPkU5ywe2fmRkliBSvYlArI/lbATT+yDvKMR2GiTi4MBZwXBTj8oJ9AFyrPFu6l/+fHyZ11DzGqvoMHSt2kCOIZ6z9oSAxAg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=ciuep69/; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ciuep69/" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=2OvFw344SsMTIobpGrnfy/6M7pj9Y2r3B8HsnkDq3a8=; b=ciuep69/wNX5ZSDXUIepaMeuLU Bdakxo04gyD+99qPl/yzFlmf/L+27ya9XdKxdG3FKePffTWgEYlSgsaeIGzW9p/8yenE5/37486Gy 8JmjvIkDIOfwKRR9Tab0XcS1jaO1wbvzDypQE+RFQInvYps5UgRohiTou6AWxqaIgXGoPcQi/2GPI 6P1Ry9CINh8ac/Tch8gOyNidSXcxIu00uzcgMENFYUs5SXZRcl9BeSX0TBuSRw5H+8XqswRBMsafr iZFph9CK0MF5BESTJ2iEHdFvlIEr5oILEV3Ni8LTV/27zPpRd0I1h4fzuX9JXaUsAopf86gbpC9HE u/RAoRjA==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wKsjJ-00000002QnP-1WWn; Thu, 07 May 2026 07:01:05 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 053E03008D6; Thu, 07 May 2026 09:01:04 +0200 (CEST) Date: Thu, 7 May 2026 09:01:03 +0200 From: Peter Zijlstra To: luca abeni Cc: Yuri Andriaccio , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org, Yuri Andriaccio Subject: Re: [RFC PATCH v5 18/29] sched/core: Cgroup v2 support Message-ID: <20260507070103.GF3126523@noisy.programming.kicks-ass.net> References: <20260430213835.62217-1-yurand2000@gmail.com> <20260430213835.62217-19-yurand2000@gmail.com> <20260505145922.GD3102624@noisy.programming.kicks-ass.net> <20260506215802.4b4130ce@nowhere> 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: <20260506215802.4b4130ce@nowhere> On Wed, May 06, 2026 at 09:58:02PM +0200, luca abeni wrote: > Hi Peter, > > On Tue, 5 May 2026 16:59:22 +0200 > Peter Zijlstra wrote: > > > On Thu, Apr 30, 2026 at 11:38:22PM +0200, Yuri Andriaccio wrote: > > > From: luca abeni > > > > > > Make rt_runtime_us and rt_period_us virtual files accessible also > > > to the cgroup v2 controller, effectively enabling the > > > RT_GROUP_SCHED mechanism to cgroups v2. > > > > Can we have a blub about why only strict periodic servers; eg. why no > > sporadic? and such... > > Maybe I am misunderstanding your question, anyway: the file is called > "rt_runtime_us", but the scheduling algorithm used to schedule the > cgroup is SCHED_DEADLINE. > So, we do not use a strictly periodic server, but a CBS, that can also > support sporadic / non-periodic activations. The interface only exposes runtime and period, as such we can only configure strict periodic servers (with implicit deadline). And I'm thinking this makes sense, esp. to start off with, but I also think it makes sense to explicitly call that out. State that this does not allow configuring sporadic servers, and hand-wave a reason for why not. Or, if we struggle to justify it, perhaps add deadline, dunno.