From: luca abeni <luca.abeni@santannapisa.it>
To: Juri Lelli <juri.lelli@redhat.com>
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: Fri, 24 Oct 2025 10:02:27 +0200 [thread overview]
Message-ID: <20251024100227.6ab1bfde@luca64> (raw)
In-Reply-To: <aPYDhjqe99F91FTW@jlelli-thinkpadt14gen4.remote.csb>
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?)
Thanks,
Luca
next prev parent reply other threads:[~2025-10-24 8:02 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-29 9:21 [RFC PATCH v3 00/24] Hierarchical Constant Bandwidth Server 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 [this message]
2025-11-03 10:32 ` Juri Lelli
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=20251024100227.6ab1bfde@luca64 \
--to=luca.abeni@santannapisa.it \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.