On Mon, 23 Nov 2020 11:28:12 -0500
Steven Rostedt <[email protected]> wrote:
> I noticed:
>
>
> [ 237.650900] enabling event benchmark_event
>
> In both traces. Could you disable CONFIG_TRACEPOINT_BENCHMARK and see if
> the issue goes away. That event kicks off a thread that spins in a tight
> loop for some time and could possibly cause some issues.
>
> It still shouldn't break things, we can narrow it down if it is the culprit.
And it probably is the issue because that thread will never sleep! It runs
a loop of:
static int benchmark_event_kthread(void *arg)
{
/* sleep a bit to make sure the tracepoint gets activated */
msleep(100);
while (!kthread_should_stop()) {
trace_do_benchmark();
/*
* We don't go to sleep, but let others run as well.
* This is basically a "yield()" to let any task that
* wants to run, schedule in, but if the CPU is idle,
* we'll keep burning cycles.
*
* Note the tasks_rcu_qs() version of cond_resched() will
* notify synchronize_rcu_tasks() that this thread has
* passed a quiescent state for rcu_tasks. Otherwise
* this thread will never voluntarily schedule which would
* block synchronize_rcu_tasks() indefinitely.
*/
cond_resched_tasks_rcu_qs();
}
return 0;
}
Did something change, where that "cond_resched_tasks_rcu_qs()" doesn't let
things progress on ARM64?
I noticed that you have PREEMPT enabled so this will only be preempted when
its schedule time runs out and something else wants to run. How would that
affect other threads?
-- Steve
