From: Juri Lelli <juri.lelli@redhat.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-kernel@vger.kernel.org, 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>,
Suleiman Souhlal <suleiman@google.com>,
Aashish Sharma <shraash@google.com>,
Shin Kawamura <kawasin@google.com>,
Vineeth Remanan Pillai <vineeth@bitbyteword.org>,
Waiman Long <longman@redhat.com>
Subject: Re: [PATCH] dl_server: Reset DL server params when rd changes
Date: Wed, 6 Nov 2024 17:08:16 +0100 [thread overview]
Message-ID: <ZyuUcJDPBln1BK1Y@jlelli-thinkpadt14gen4.remote.csb> (raw)
In-Reply-To: <20241104174109.GA1044726@google.com>
On 04/11/24 17:41, Joel Fernandes wrote:
> On Mon, Nov 04, 2024 at 11:54:36AM +0100, Juri Lelli wrote:
...
> > I added a printk in __dl_server_attach_root which is called after the
> > dynamic rd is built to transfer bandwidth to it.
> >
> > __dl_server_attach_root came with d741f297bceaf ("sched/fair: Fair
> > server interface"), do you have this change in your backport?
>
> You nailed it! Our 5.15 backport appears to be slightly older and is missing
> this from topology.c as you mentioned. Thanks for clarifying!
>
>
> /*
> * Because the rq is not a task, dl_add_task_root_domain() did not
> * move the fair server bw to the rd if it already started.
> * Add it now.
> */
> if (rq->fair_server.dl_server)
> __dl_server_attach_root(&rq->fair_server, rq);
>
> >
> > > So if rd changes during boot initialization, the correct dl_bw has to be
> > > updated AFAICS. Also if cpusets are used, the rd for a CPU may change.
> >
> > cpusets changes are something that I still need to double check. Will
> > do.
> >
>
> Sounds good, that would be good to verify.
So, I played a little bit with it and came up with a simple set of ops
that point out an issue (default fedora server install):
echo Y >/sys/kernel/debug/sched/verbose
echo +cpuset >/sys/fs/cgroup/cgroup.subtree_control
echo 0-7 > /sys/fs/cgroup/user.slice/cpuset.cpus
echo 6-7 > /sys/fs/cgroup/user.slice/cpuset.cpus.exclusive
echo root >/sys/fs/cgroup/user.slice/cpuset.cpus.partition
The domains are rebuilt correctly, but we end up with a null total_bw.
The conditional call above takes care correctly of adding back dl_server
per-rq bandwidth when we pass from the single domain to the 2 exclusive
ones, but I noticed that we go through partition_sched_domains_locked()
twice for a single write of 'root' and the second one, since it's not
actually destroying/rebuilding anything, is resetting total_bw w/o
addition dl_server contribution back.
Now, not completely sure why we need to go through partition_sched_
domains_locked() twice, as we have (it also looked like a pattern from
other call paths)
update_prstate()
-> update_cpumasks_hier()
-> rebuild_sched_domains_locked() <- right at the end
-> update_partition_sd_lb()
-> rebuild_sched_domains_locked() <- right after the above call
Removing the first call does indeed fix the issue and domains look OK,
but I'm pretty sure I'm missing all sort of details and corner cases.
Waiman (now Cc-ed), maybe you can help here understanding why the two
back to back calls are needed?
Thanks!
Juri
next prev parent reply other threads:[~2024-11-06 16:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 22:51 Joel Fernandes (Google)
2024-10-30 14:30 ` Juri Lelli
2024-10-30 19:50 ` Joel Fernandes
2024-11-04 10:54 ` Juri Lelli
2024-11-04 17:41 ` Joel Fernandes
2024-11-06 16:08 ` Juri Lelli [this message]
2024-11-06 18:05 ` Waiman Long
2024-11-08 4:40 ` Waiman Long
2024-11-08 10:40 ` Juri Lelli
2024-11-09 3:30 ` Waiman Long
2024-11-09 18:18 ` Waiman Long
2024-11-11 9:37 ` Juri Lelli
2024-11-11 12:24 ` Juri Lelli
2024-10-30 15:54 ` kernel test robot
2024-10-30 17:06 ` kernel test robot
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=ZyuUcJDPBln1BK1Y@jlelli-thinkpadt14gen4.remote.csb \
--to=juri.lelli@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=joel@joelfernandes.org \
--cc=kawasin@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=shraash@google.com \
--cc=suleiman@google.com \
--cc=vincent.guittot@linaro.org \
--cc=vineeth@bitbyteword.org \
--cc=vschneid@redhat.com \
/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®