[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160830064724.GX10153@twins.programming.kicks-ass.net>
Date: Tue, 30 Aug 2016 08:47:24 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Jiri Olsa <jolsa@...hat.com>
Cc: Vegard Nossum <vegard.nossum@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Stephane Eranian <eranian@...gle.com>,
Vince Weaver <vincent.weaver@...ne.edu>,
Ingo Molnar <mingo@...nel.org>,
David Carrillo-Cisneros <davidcc@...gle.com>,
"H. Peter Anvin" <hpa@...or.com>, Kan Liang <kan.liang@...el.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Paul Turner <pjt@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perf/core] perf/core: Check return value of the
perf_event_read() IPI
On Mon, Aug 29, 2016 at 08:58:41PM +0200, Jiri Olsa wrote:
> couldn't we just call smp_call_function_single(cpu_to_read, __perf_event_read, ...
> once we read oncpu != -1 ?
>
Yes, and at that point we can simply revert this WARN, because that is
exactly the same.
Which I think is what I'm going to do.
If oncpu is not valid, the sched_out that made it invalid will have
updated the event count and we're good.
All I'll leave is an explicit comment that we've ignored the
smp_call_function_single() return value on purpose.
Powered by blists - more mailing lists