From: Juri Lelli <juri.lelli@redhat.com>
To: luca abeni <luca.abeni@santannapisa.it>
Cc: Yuri Andriaccio <yurand2000@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
linux-kernel@vger.kernel.org,
Yuri Andriaccio <yuri.andriaccio@santannapisa.it>
Subject: Re: [RFC PATCH v3 00/24] Hierarchical Constant Bandwidth Server
Date: Mon, 3 Nov 2025 11:32:53 +0100 [thread overview]
Message-ID: <aQiE1ULtInJS6X4R@jlelli-thinkpadt14gen4.remote.csb> (raw)
In-Reply-To: <20251024100227.6ab1bfde@luca64>
On 24/10/25 10:02, luca abeni wrote:
> Hi Juri,
>
> On Mon, 20 Oct 2025 11:40:22 +0200
> Juri Lelli <juri.lelli@redhat.com> wrote:
> [...]
> > > > - The first patch which removed fair-servers' bandwidth
> > > > accounting has been removed, as it was deemed wrong. You can find
> > > > the last version of this removed patch, just for history reasons,
> > > > here:
> > > > https://lore.kernel.org/all/20250903114448.664452-1-yurand2000@gmail.com/
> > > >
> > >
> > > Peter wasn't indeed happy with that patch, but I am not sure we
> > > finished that discussion. Both myself and Luca had further
> > > objections to what Peter said, but not further replies after (which
> > > can very well be a sign that he is still adamnt in saying no go
> > > away :). Peter?
> > >
> > > https://lore.kernel.org/lkml/aLk9BNnFYZ3bhVAE@jlelli-thinkpadt14gen4.remote.csb/
> > > https://lore.kernel.org/lkml/20250904091217.78de3dde@luca64/
> >
> > I had a quick chat with Peter on IRC about this. We now seem to agree
> > that a third option would be to move to explicitly account
> > dl-server(s), correspondingly moving from a 95% to 100% limit. That
> > would also make our life easier in the future with additional
> > dl-servers (e.g. scx-server).
> >
> > What do you think?
>
> This looks like another good solution, thanks!
>
> So, if I understand well with this approach
> /proc/sys/kernel/sched_rt_{runtime, period}_us would be set to 100% as
> a default, right?
>
> It is often useful to know what is the maximum CPU utilization that can
> be guaranteed to real-time tasks... With this approach, it would be
> 100% - <dl_server utilization>, but this can change when scx servers are
> added... What about making this information available to userspace
> programs? (maybe /proc/sys/kernel/sched_rt_{runtime, period}_us could
> provide such information? Or is it better to add a new interface?)
Not sure. If we set it to 100% by default (as you suggest, which makes
sense to me) I wonder what would be a usecase/need to set it to less
than 100% later on. We have the debug interface for tweaking dl-servers
and sched_rt_ interface doesn't distinguish between DEADLINE and RT
anyway (so no way to leave some "bandwidth" around for RT tasks).
Maybe it's an interface we want to start deprecating and we can come up
with something better and/or more useful? Peter?
prev parent reply other threads:[~2025-11-03 10:33 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-29 9:21 Yuri Andriaccio
2025-09-29 9:21 ` [RFC PATCH v3 01/24] sched/deadline: Do not access dl_se->rq directly Yuri Andriaccio
2025-10-02 13:10 ` Juri Lelli
2025-09-29 9:21 ` [RFC PATCH v3 02/24] sched/deadline: Distinct between dl_rq and my_q Yuri Andriaccio
2025-10-02 13:29 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 03/24] sched/rt: Pass an rt_rq instead of an rq where needed Yuri Andriaccio
2025-10-02 14:01 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 04/24] sched/rt: Move some functions from rt.c to sched.h Yuri Andriaccio
2025-10-02 14:12 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 05/24] sched/rt: Disable RT_GROUP_SCHED Yuri Andriaccio
2025-10-02 15:35 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 06/24] sched/rt: Introduce HCBS specific structs in task_group Yuri Andriaccio
2025-10-02 15:58 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 07/24] sched/core: Initialize root_task_group Yuri Andriaccio
2025-10-02 16:33 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 08/24] sched/deadline: Add dl_init_tg Yuri Andriaccio
2025-10-08 6:25 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 09/24] sched/rt: Add {alloc/free}_rt_sched_group Yuri Andriaccio
2025-10-08 7:28 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 10/24] sched/deadline: Account rt-cgroups bandwidth in deadline tasks schedulability tests Yuri Andriaccio
2025-09-29 9:22 ` [RFC PATCH v3 11/24] sched/rt: Add rt-cgroups' dl-servers operations Yuri Andriaccio
2025-10-08 10:26 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 12/24] sched/rt: Update task event callbacks for HCBS scheduling Yuri Andriaccio
2025-10-09 6:54 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 13/24] sched/rt: Update rt-cgroup schedulability checks Yuri Andriaccio
2025-09-29 11:03 ` Markus Elfring
2025-10-09 9:51 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 14/24] sched/rt: Allow zeroing the runtime of the root control group Yuri Andriaccio
2025-10-09 13:54 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 15/24] sched/rt: Remove old RT_GROUP_SCHED data structures Yuri Andriaccio
2025-09-29 9:22 ` [RFC PATCH v3 16/24] sched/core: Cgroup v2 support Yuri Andriaccio
2025-09-29 9:22 ` [RFC PATCH v3 17/24] sched/rt: Remove support for cgroups-v1 Yuri Andriaccio
2025-10-15 11:51 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 18/24] sched/deadline: Allow deeper hierarchies of RT cgroups Yuri Andriaccio
2025-10-15 14:24 ` Juri Lelli
2025-09-29 9:22 ` [RFC PATCH v3 19/24] sched/rt: Add rt-cgroup migration Yuri Andriaccio
2025-09-29 9:22 ` [RFC PATCH v3 20/24] sched/rt: Add HCBS migration related checks and function calls Yuri Andriaccio
2025-09-29 9:22 ` [RFC PATCH v3 21/24] sched/deadline: Make rt-cgroup's servers pull tasks on timer replenishment Yuri Andriaccio
2025-09-29 9:22 ` [RFC PATCH v3 22/24] sched/deadline: Fix HCBS migrations on server stop Yuri Andriaccio
2025-09-29 9:22 ` [RFC PATCH v3 23/24] sched/core: Execute enqueued balance callbacks when changing allowed CPUs Yuri Andriaccio
2025-09-29 9:22 ` [RFC PATCH v3 24/24] sched/core: Execute enqueued balance callbacks when migrating task betweeen cgroups Yuri Andriaccio
2025-10-02 9:00 ` [RFC PATCH v3 00/24] Hierarchical Constant Bandwidth Server Juri Lelli
2025-10-15 14:35 ` Juri Lelli
2025-10-15 15:17 ` Yuri Andriaccio
2025-10-20 9:40 ` Juri Lelli
2025-10-24 8:02 ` luca abeni
2025-11-03 10:32 ` Juri Lelli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQiE1ULtInJS6X4R@jlelli-thinkpadt14gen4.remote.csb \
--to=juri.lelli@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.abeni@santannapisa.it \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=yurand2000@gmail.com \
--cc=yuri.andriaccio@santannapisa.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®