[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160216100121.6ef2145d@gandalf.local.home>
Date: Tue, 16 Feb 2016 10:01:21 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Denis Kirjanov <kda@...ux-powerpc.org>
Cc: linux-kernel@...r.kernel.org, paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH 1/2] tracing/mm: don't trace kfree on offline CPUs
On Tue, 16 Feb 2016 08:52:24 +0300
Denis Kirjanov <kda@...ux-powerpc.org> wrote:
> On 2/15/16, Steven Rostedt <rostedt@...dmis.org> wrote:
> > On Sun, 14 Feb 2016 23:19:42 +0300
> > Denis Kirjanov <kda@...ux-powerpc.org> wrote:
> >
> >
> >> >> TP_PROTO(unsigned long call_site, const void *ptr),
> >> >>
> >> >> - TP_ARGS(call_site, ptr)
> >> >> + TP_ARGS(call_site, ptr),
> >> >> +
> >> >> + /*
> >> >> + * This trace can be potentially called from an offlined cpu.
> >> >> + * Since trace points use RCU and RCU should not be used from
> >> >> + * offline cpus, filter such calls out.
> >> >> + * While this trace can be called from a preemptable section,
> >> >> + * it has no impact on the condition since tasks can migrate
> >> >> + * only from online cpus to other online cpus. Thus its safe
> >> >> + * to use raw_smp_processor_id.
> >> >> + */
> >> >> + TP_CONDITION(cpu_online(raw_smp_processor_id()))
> >> >
> >> > This is starting to become a common occurrence. Perhaps it is best to
> >> > just hardcode this into the tracepoint code itself?
> >>
> >> Can you take it as a fix for now. I'll post the follow-up patch then
> >> for rcu and offline cpus
> >> issue.
> >
> > Actually, I prefer not to add more checks for cpu_online(), if its
> > going to become the default.
> >
> > Does this work for you instead?
>
> Hm, somehow it doesn't work:
But your patch works? Strange, because my exit condition is done before
the conditional part of the trace event. Thus, if this didn't work,
than your original patch should not work either.
-- Steve
Powered by blists - more mailing lists