[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161122190550.GZ26852@two.firstfloor.org>
Date: Tue, 22 Nov 2016 11:05:50 -0800
From: Andi Kleen <andi@...stfloor.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Andi Kleen <andi@...stfloor.org>,
Peter Zijlstra <peterz@...radead.org>,
Jiri Olsa <jolsa@...hat.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Josh Triplett <josh@...htriplett.org>,
Jan Stancek <jstancek@...hat.com>
Subject: Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!
On Tue, Nov 22, 2016 at 09:39:45AM -0500, Steven Rostedt wrote:
> On Mon, 21 Nov 2016 10:37:00 -0800
> Andi Kleen <andi@...stfloor.org> wrote:
>
>
> > Here is it again untruncated:
> >
> > http://halobates.de/tracepoint-trace
>
> BTW, what tool did you use to generate this?
perf and Intel PT, with the disassembler patches added and udis86
installed:
https://git.kernel.org/cgit/linux/kernel/git/ak/linux-misc.git/log/?h=perf/disassembler-2
http://udis86.sourceforge.net/
You need a CPU that supports PT, like Broadwell, Skylake, Goldmont.
# enable trace point
perf record -e intel_pt// -a sleep X
perf script --itrace=i0ns --ns -F cpu,ip,time,asm,sym
On Skylake can also get more accurate timing by enabling cycle timing
(at the cost of some overhead)
perf record -e intel_pt/cyc=1,cyc_thresh=1/ -a ...
The earlier trace didn't have that enabled.
-Andi
Powered by blists - more mailing lists