From: Joel Fernandes <joel@joelfernandes.org>
To: Daniel Bristot de Oliveira <bristot@redhat.com>,
rcu@vger.kernel.org, paulmck@kernel.org, frederic@kernel.org
Cc: Florent Carli <fcarli@gmail.com>, linux-rt-users@vger.kernel.org
Subject: Re: RCU stall warnings even with rcu_nocbs and rcu_nocb_poll
Date: Thu, 6 Oct 2022 13:31:43 +0000 [thread overview]
Message-ID: <Yz7Yv6d3v3oETZYI@google.com> (raw)
In-Reply-To: <e86930e4-4b9c-cf18-5119-50c6910b76dd@redhat.com>
On Wed, Oct 05, 2022 at 06:03:39PM +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.
Isolating a CPU does not mean that RCU activity is forbidden on it, even with
nohz_full, if the CPU enters the kernel (say syscall or interrupt), then it
may enter a read-side critical section so RCU will be watching it, and such
CPU will have to report quiescent state.
> > As per the documentation, if I use rcutree.kthread_prio with a
> > priority > my RT task, then the rcu stall does not happen.
Yes, it sounds like the main RCU GP thread (mostly called rcu_preempt thread)
in your system is competing with your RT task. Increase kthread_prio is
standard procedure to resolve this issue, as you did.
> > 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?
It is not possible to provide further help without more info, in particular
are you using nohz_full and isolcpus options? Can you provide kernel
and #CPU configuration?
Happy to look further! Also adding some more folks who know a lot about this
stuff and +rcu list for archives.
thanks,
- Joel
>
> Adding Joel because we had a chat about it during lpc...
>
> > Thanks.
> >
> -- Daniel
>
next prev parent reply other threads:[~2022-10-06 13:33 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
2022-10-06 13:31 ` Joel Fernandes [this message]
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=Yz7Yv6d3v3oETZYI@google.com \
--to=joel@joelfernandes.org \
--cc=bristot@redhat.com \
--cc=fcarli@gmail.com \
--cc=frederic@kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rcu@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.