From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: Florent Carli <fcarli@gmail.com>,
linux-rt-users@vger.kernel.org,
"Joel Fernandes (Google)" <joel@joelfernandes.org>
Subject: Re: RCU stall warnings even with rcu_nocbs and rcu_nocb_poll
Date: Thu, 6 Oct 2022 08:57:15 +0200 [thread overview]
Message-ID: <Yz58S8PXdBOO9bhL@linutronix.de> (raw)
In-Reply-To: <e86930e4-4b9c-cf18-5119-50c6910b76dd@redhat.com>
On 2022-10-05 18:03:39 [+0200], Daniel Bristot de Oliveira wrote:
> On 10/5/22 18:01, Florent Carli wrote:
> > Hello,
> >
> > I'm trying to isolate some cores to run a CPU-bound real-time task and
> > even though I'm using rcu_nocbs and rcu_nocb_poll, I can see the rcuc
> > threads wake up, and I get RCU stall warnings on the isolated core.
> > As per the documentation, if I use rcutree.kthread_prio with a
> > priority > my RT task, then the rcu stall does not happen.
> >
> > However I find it confusing: why are the rcuc threads woken up on the
> > isolated cores despite using rcu_nocbs and rcu_nocb_poll? In my (very
> > likely erroneous) understanding, I shouldn't have to fiddle with rcu
> > priority... In other words, how come I get rcu stalls on cores that
> > have no rcu callbacks?
There are different things:
- with CONFIG_RCU_NOCB_CPU you get addition threads and can move the
rcuo* theads away from the isolated CPU. That means the callbacks will
be handled on a different CPU.
- you still need to track/ follow the grace period. This still happens
in the rcuc thread. To get around this you need to use NO_HZ_FULL with
isolcpus/rcu_nocbs.
> Adding Joel because we had a chat about it during lpc...
>
> > Thanks.
> >
> -- Daniel
Sebastian
next prev parent reply other threads:[~2022-10-06 6:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 16:01 RCU stall warnings even with rcu_nocbs and rcu_nocb_poll Florent Carli
2022-10-05 16:03 ` Daniel Bristot de Oliveira
2022-10-06 6:57 ` Sebastian Andrzej Siewior [this message]
2022-10-06 13:31 ` Joel Fernandes
2022-10-06 14:13 ` Paul E. McKenney
2022-10-07 15:06 ` Florent Carli
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=Yz58S8PXdBOO9bhL@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=bristot@redhat.com \
--cc=fcarli@gmail.com \
--cc=joel@joelfernandes.org \
--cc=linux-rt-users@vger.kernel.org \
/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.