lkml.org 
[lkml]   [2020]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] kfence: Avoid stalling work queue task without allocations
On Mon, 23 Nov 2020 11:28:12 -0500
Steven Rostedt <rostedt@goodmis.org> 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

\
 
 \ /
  Last update: 2020-11-23 17:42    [W:0.369 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site