From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 6331C34EEF3 for ; Wed, 21 Jan 2026 10:21:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768990885; cv=none; b=LnhgBz5Cvlmq5hkAr9l+v0AjShdrwTTs8FEAIiyPQNS20sWgPCjRqwy3WyFbfVZnX4T8OFg6abbVibyHSN7saX0vlH2A1BY0aH6fl9zCXQy1K7g67gniyTpyvQ0nzHdOZ5o05Gs5TIIM/09QrDAgOpV3/zngITTxpPKkBPxzAGw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768990885; c=relaxed/simple; bh=wm3DaZQ4qSoYNgej4rz1rG4Wrjg3AFYFOfktWmZUaic=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QQUYTLcn+nb4ortcbFHCBxbhU0Y9VEZFETthOZqbNl5/x4cFeYfmuoclNro3AHPyvkWIT/H0FZsK4HkUwzVWlV/0iXCSnUqmjnXpo36ckx4kxuIozs7EXTbkFalWkIRXJyMKL5eNJ7aCuhCYP2FXvD+oJ8K9/9CQmKv3KkE3mY0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QVCQ/gjH; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=lrl+K+kL; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QVCQ/gjH"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="lrl+K+kL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768990881; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p/1NQCHc5hTJJpWmITv8DWgIR/VI4nxQDTsgnjHEaIA=; b=QVCQ/gjHMDsld01Bg47HFdU9WNsnkeadr176KTJ72S/5EjrT9EwsqPr91kBBesJz4SoGx9 LivC1rSYkqkHmtEZJ2PgGc0RSbz7qhzeMutbw3aE0Y4x6Egn0TPNTq4D1JQxqyiiLjyMLO TM6aQVtWsRwiAJfqE0m0WpeA7HDL65k= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-265-fu9KTDcLMneT7a4_wUWGyg-1; Wed, 21 Jan 2026 05:21:20 -0500 X-MC-Unique: fu9KTDcLMneT7a4_wUWGyg-1 X-Mimecast-MFC-AGG-ID: fu9KTDcLMneT7a4_wUWGyg_1768990879 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-48025e12b5bso37666995e9.2 for ; Wed, 21 Jan 2026 02:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768990879; x=1769595679; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=p/1NQCHc5hTJJpWmITv8DWgIR/VI4nxQDTsgnjHEaIA=; b=lrl+K+kLiDJdHtuJ72Qd17uenVJ3ITzrD/WGatW+KyedTALS4USqi2i+XPa4/eelkF 4vP6BfKJTyGuiBmBdh0/9GNcKN2SZC7mwHm62dzqRTaoOgZmHwlMeDqCWHCdRZhdoecy kxCPatOuUde+RoWhRw9mjrqAlAyZcp/Lcc+fRpUgHEhMlB+EPmxgczNnOgfGLkZGTUcW ShLQUxUqWq/4+d+cXY3+bCCSdmp/Z1iZfEQKKKNW5JxNaYr2oe76W2Nf3KSB8qDIWSb7 RyRZZwygXhquB5pmOZxc9Ndg+zusrClEw4o8W+cJrckOxOb1dNkqu1Tx0i8Ew+bQOtGN pb6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768990879; x=1769595679; h=in-reply-to:content-disposition: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; bh=p/1NQCHc5hTJJpWmITv8DWgIR/VI4nxQDTsgnjHEaIA=; b=jafVy2HmnXLwAR+rNg/l98rNLNYre8c+4NbYnBbhVhWw6cVN09ZelQ42Hg1763VRrZ p/8tGQyLDH3GpStlzmfcWVbGlCXHVaJhZH071pLtXQGBEZNExPJS21knZaZsfdnV6EM/ 3xgcbByJ0ggs5O/yE8sOjUjGI7IEh7vEQP/pO9JiiyoyDU3Hc1ooRva6W78CkjFrLRYg 7LwzgNXLRKMYLOoOHF/X+3hmIK6gAAMCnX9OC426HDMTWFC3UWBheunX9cRifR1hAsQh pNE30MCPLnzejmiXCe5nt89aOJitbGkLQHZRKFAgN+79t8mKX+ZHJx0crl51TMJjLo81 B+Ag== X-Forwarded-Encrypted: i=1; AJvYcCWqEdCauTVrvO7gunG8i9EOKWJh/tQHzY0CuTx0Ygbu6NIfDLnyY4W1LIHB7U08rvHrgbCvvxuOuzFrVLQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzXh5PmYrgbot6hAcgBOJTzovUO7RX/wskIwk3qkfry6dzVlvOc XUqGU1JuQmjGedhF4N5jlOSnJID8WRRYN3twv8+BZi04Ia6OklbJZIP2NqtY4wlTKxKDlXvbHzK y7BTh7JDKph5ZswQ3NGUyTqAO05d2LNII8z2XSXovD/0Tidink9LcvdwHrqRUowChTg== X-Gm-Gg: AZuq6aIzYGcPFvuedZgQXpu/AfJM6e7RwCEy18l0PxaQkLI8Go7usYJ6QI5o+udRfw2 +ur/E564WbEVWa+8CJ+6noX9PxZek60rDyiya0GiDJ7rkC2Ye0bo1X/wFCwmkWjuVfkxWbshSLD uODmZI+MZ1YnL7y5Y5vfXUrWO0waX+NRwIFBMi7uDrKmx3LybWcbj1cchltvcLgUCAmMN2U1apa 1R2IbIayAWNUiZ2spnLj+m1IOqWG36vMm4zYOYqZzP3eR0WkIoyPP4Z889X3y4v4s3XaBLCMocA JNezJawbuI71Xzc5468hbuTAuRyxsbmUVF+a9fktKRqapRsIysOCsupk6+B6cTM0wCVizce+mA4 2g+F3+T1C8MdRneVsaoDsA1dFMir4FpdnT3OKDc1i X-Received: by 2002:a05:600c:1990:b0:475:e09c:960e with SMTP id 5b1f17b1804b1-4803e7f3d7bmr70602485e9.32.1768990878707; Wed, 21 Jan 2026 02:21:18 -0800 (PST) X-Received: by 2002:a05:600c:1990:b0:475:e09c:960e with SMTP id 5b1f17b1804b1-4803e7f3d7bmr70602105e9.32.1768990878236; Wed, 21 Jan 2026 02:21:18 -0800 (PST) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.129.40]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4289b789sm358061835e9.1.2026.01.21.02.21.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 02:21:17 -0800 (PST) Date: Wed, 21 Jan 2026 11:21:15 +0100 From: Juri Lelli To: Yuri Andriaccio Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org, Luca Abeni , Yuri Andriaccio Subject: Re: [RFC PATCH v4 14/28] sched/rt: Update rt-cgroup schedulability checks Message-ID: References: <20251201124205.11169-1-yurand2000@gmail.com> <20251201124205.11169-15-yurand2000@gmail.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: <20251201124205.11169-15-yurand2000@gmail.com> Hello, On 01/12/25 13:41, Yuri Andriaccio wrote: > From: luca abeni > > Update sched_group_rt_runtime/period and sched_group_set_rt_runtime/period > to use the newly defined data structures and perform necessary checks to > update both the runtime and period of a given group. > > The set functions call tg_set_rt_bandwidth() which is also updated: > - Use the newly added HCBS dl_bandwidth structure instead of rt_bandwidth. > - Update __rt_schedulable() to check for numerical issues: > - Prevent a non-zero runtime that is too small, since a non-zero very > small runtime will make the servers behave as they had zero runtime. > - Since some computation use signed integers, the period might be so > big that when read as a signed integer becomes a negative number, and > we don't want that. If the period satisfies this prerequisite, also > the runtime will do, since the runtime is always less than or equal > to the period. > - Update tg_rt_schedulable(), used when walking the cgroup tree to check > if all invariants are met: > - Update most of the instructions to obtain data from the newly added > data structures (dl_bandwidth). > - If the task group is the root group, run a total bandwidth check with > the newly added dl_check_tg() function. > - After all checks are successful, if the changed group is not the root > cgroup, update the assigned runtime and period to all the local > deadline servers. > - Additionally use a mutex guard instead of manually locking/unlocking. > > Add dl_check_tg(), which performs an admission control test similar to > __dl_overflow, but this time we are updating the cgroup's total bandwidth > rather than scheduling a new DEADLINE task or updating a non-cgroup > deadline server. > > Finally, prevent creation of a cgroup hierarchy with depth greater than > two, as this will be addressed in a future patch. A depth two hierarchy > is sufficient for now for testing the patchset. > > Co-developed-by: Alessio Balsini > Signed-off-by: Alessio Balsini > Co-developed-by: Andrea Parri > Signed-off-by: Andrea Parri > Co-developed-by: Yuri Andriaccio > Signed-off-by: Yuri Andriaccio > Signed-off-by: luca abeni > --- ... > #ifdef CONFIG_RT_GROUP_SCHED > +int dl_check_tg(unsigned long total) > +{ > + unsigned long flags; > + int which_cpu; > + int cap; > + struct dl_bw *dl_b; > + u64 gen = ++dl_cookie; > + > + for_each_possible_cpu(which_cpu) { > + rcu_read_lock_sched(); > + > + if (!dl_bw_visited(which_cpu, gen)) { > + cap = dl_bw_capacity(which_cpu); > + dl_b = dl_bw_of(which_cpu); > + > + raw_spin_lock_irqsave(&dl_b->lock, flags); > + > + if (dl_b->bw != -1 && > + cap_scale(dl_b->bw, cap) < dl_b->total_bw + cap_scale(total, cap)) { > + raw_spin_unlock_irqrestore(&dl_b->lock, flags); > + rcu_read_unlock_sched(); > + > + return 0; > + } > + > + raw_spin_unlock_irqrestore(&dl_b->lock, flags); > + } > + > + rcu_read_unlock_sched(); I believe we can use lock guards in the above? ... > @@ -2108,6 +2107,20 @@ static int __rt_schedulable(struct task_group *tg, u64 period, u64 runtime) > .rt_runtime = runtime, > }; > > + /* > + * Since we truncate DL_SCALE bits, make sure we're at least > + * that big. > + */ > + if (runtime != 0 && runtime < (1ULL << DL_SCALE)) > + return -EINVAL; > + > + /* > + * Since we use the MSB for wrap-around and sign issues, make > + * sure it's not set (mind that period can be equal to zero). > + */ > + if (period & (1ULL << 63)) > + return -EINVAL; > + This is the same as in __checkparam_dl(), is it? Maybe we can create an helper? Thanks, Juri