From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, andrea.parri@amarulasolutions.com,
rostedt@goodmis.org
Subject: Re: Question about sched_setaffinity()
Date: Wed, 1 May 2019 12:12:13 -0700 [thread overview]
Message-ID: <20190501191213.GX3923@linux.ibm.com> (raw)
In-Reply-To: <20190430115551.GT2623@hirez.programming.kicks-ass.net>
On Tue, Apr 30, 2019 at 01:55:51PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 30, 2019 at 03:51:30AM -0700, Paul E. McKenney wrote:
> > > Then I'm not entirely sure how we can return 0 and not run on the
> > > expected CPU. If we look at __set_cpus_allowed_ptr(), the only paths out
> > > to 0 are:
> > >
> > > - if the mask didn't change
> > > - if we already run inside the new mask
> > > - if we migrated ourself with the stop-task
> > > - if we're not in fact running
> > >
> > > That last case should never trigger in your circumstances, since @p ==
> > > current and current is obviously running. But for completeness, the
> > > wakeup of @p would do the task placement in that case.
> >
> > Are there some diagnostics I could add that would help track this down,
> > be it my bug or yours?
>
> Maybe limited function trace combined with the scheduling tracepoints
> would give clue.
>
> Trouble is, I forever forget how to set that up properly :/ Maybe
> something along these lines:
>
> $ trace-cmd record -p function_graph -g sched_setaffinity -g migration_cpu_stop -e
> sched_migirate_task -e sched_switch -e sched_wakeup
>
> Also useful would be:
>
> echo 1 > /proc/sys/kernel/traceoff_on_warning
>
> which ensures the trace stops the moment we find fail.
OK, what I did was to apply the patch at the end of this email to -rcu
branch dev, then run rcutorture as follows:
nohup tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 8 --duration 2 --configs "TRIVIAL" --bootargs "trace_event=sched:sched_switch,sched:sched_wakeup ftrace=function_graph ftrace_graph_filter=sched_setaffinity,migration_cpu_stop"
This resulted in the console output that I placed here:
http://www2.rdrop.com/~paulmck/submission/console.log.gz
But I don't see calls to sched_setaffinity() or migration_cpu_stop().
Steve, is something else needed on the kernel command line in addition to
the following?
ftrace=function_graph ftrace_graph_filter=sched_setaffinity,migration_cpu_stop
Thanx, Paul
------------------------------------------------------------------------
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index da04b5073dc3..ceae80522d64 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -680,12 +680,18 @@ static struct rcu_torture_ops tasks_ops = {
static void synchronize_rcu_trivial(void)
{
int cpu;
+ static int dont_trace;
for_each_online_cpu(cpu) {
- while (raw_smp_processor_id() != cpu)
- rcutorture_sched_setaffinity(current->pid,
- cpumask_of(cpu));
- WARN_ON_ONCE(raw_smp_processor_id() != cpu);
+ if (!READ_ONCE(dont_trace))
+ tracing_on();
+ rcutorture_sched_setaffinity(current->pid, cpumask_of(cpu));
+ tracing_off();
+ if (raw_smp_processor_id() != cpu) {
+ WRITE_ONCE(dont_trace, 1);
+ WARN_ON_ONCE(1);
+ ftrace_dump(DUMP_ALL);
+ }
}
}
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index caffee644932..edaf0ca22ff7 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3495,6 +3495,7 @@ void __init rcu_init(void)
rcu_par_gp_wq = alloc_workqueue("rcu_par_gp", WQ_MEM_RECLAIM, 0);
WARN_ON(!rcu_par_gp_wq);
srcu_init();
+ tracing_off();
}
#include "tree_stall.h"
next prev parent reply other threads:[~2019-05-01 19:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-27 18:02 Paul E. McKenney
2019-04-30 10:03 ` Peter Zijlstra
2019-04-30 10:51 ` Paul E. McKenney
2019-04-30 11:55 ` Peter Zijlstra
2019-05-01 19:12 ` Paul E. McKenney [this message]
2019-05-01 19:16 ` Steven Rostedt
2019-05-01 20:27 ` Paul E. McKenney
2019-05-07 22:16 ` Paul E. McKenney
2019-05-09 17:36 ` Paul E. McKenney
2019-05-09 19:36 ` Paul E. McKenney
2019-05-10 12:08 ` Peter Zijlstra
2019-05-10 23:07 ` Paul E. McKenney
2019-05-11 21:45 ` Andrea Parri
2019-05-12 0:39 ` Paul E. McKenney
2019-05-12 1:05 ` Andrea Parri
2019-05-13 12:20 ` Paul E. McKenney
2019-05-13 15:37 ` Joel Fernandes
2019-05-13 15:53 ` Paul E. McKenney
2019-05-13 8:10 ` Peter Zijlstra
2019-05-13 12:19 ` Paul E. McKenney
2019-05-09 21:40 ` Andrea Parri
2019-05-09 21:56 ` Andrea Parri
2019-05-09 22:17 ` Paul E. McKenney
2019-05-10 6:32 ` Andrea Parri
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=20190501191213.GX3923@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome