[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240705081052.GA11386@noisy.programming.kicks-ass.net>
Date: Fri, 5 Jul 2024 10:10:52 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Radoslaw Zielonek <radoslaw.zielonek@...il.com>
Cc: mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
oleg@...hat.com, brauner@...nel.org, akpm@...ux-foundation.org,
tandersen@...flix.com, bigeasy@...utronix.de,
vincent.whitchurch@...s.com, kunyu@...china.com, ardb@...nel.org,
linux-kernel@...r.kernel.org, liam.howlett@...cle.com,
syzbot+a941018a091f1a1f9546@...kaller.appspotmail.com,
syzkaller-bugs@...glegroups.com
Subject: Re: [RFC] Signaling overhead on RT tasks is causing RCU stall
On Fri, Jul 05, 2024 at 09:56:23AM +0200, Radoslaw Zielonek wrote:
> Hello,
>
> I'm working on syzbot bug: rcu detected stall in validate_mm
> https://syzkaller.appspot.com/bug?extid=a941018a091f1a1f9546.
> I have analyzed this issue and here is what I found:
>
> When too many signals are sent to the RT task, the overhead becomes very high.
> The task cannot perform its job and as a consquenece the rt_runtime (0.95s)
> is not reached even after hundreds of seconds.
I'm having trouble parsing this. What overhead becomes high? Is the task
spending time in-kernel? Because if the task is spending time in-user
handling all its signals, it should accumulate runtime just fine.
That is, your analysis seems to leave out / gloss over the important
bit.
Powered by blists - more mailing lists