[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160929145455.GA29214@kernel.org>
Date: Thu, 29 Sep 2016 11:54:55 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Jiri Olsa <jolsa@...nel.org>,
Michael Trapp <michael.trapp@....com>,
"Long, Wai Man" <waiman.long@....com>,
Stanislav Ievlev <stanislav.ievlev@...il.com>,
Kim Phillips <kim.phillips@....com>,
lkml <linux-kernel@...r.kernel.org>,
Don Zickus <dzickus@...hat.com>, Joe Mario <jmario@...hat.com>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
David Ahern <dsahern@...il.com>,
Andi Kleen <andi@...stfloor.org>,
Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCHv4 00/57] perf c2c: Add new tool to analyze cacheline
contention on NUMA systems
Em Thu, Sep 29, 2016 at 11:19:12AM +0200, Peter Zijlstra escreveu:
> On Thu, Sep 22, 2016 at 05:36:28PM +0200, Jiri Olsa wrote:
> > sending new version of c2c patches (v3) originally posted in here:
> > http://lwn.net/Articles/588866/
> I'll just keep repeating; this is not the tool I want :-( I'll not block
> this tool, but I also think its far less usable than it should've been.
Well, I think its an experimentation with using that info, one that
people have been using and seemingly finding and fixing problems.
Requires more work than the way you describe(d) various times, tho,
indeed. :-\
> https://lkml.kernel.org/r/20151209093402.GM6356@twins.programming.kicks-ass.net
> What I want is a tool that maps memop events (any PEBS memops) back to a
> 'type::member' form and sorts on that. That doesn't rely on the PEBS
> 'Data Linear Address' field, as that is useless for dynamically
> allocated bits. Instead it would use the IP and Dwarf information to
> deduce the 'type::member' of the memop.
> I want pahole like output, showing me where the hits (green) and misses
> (red) are in a structure.
> I want to be able to 'perf memops report -EC task_struct' and see the
> expanded task_struct (as per 'pahole -EC task_struct') annotated, not a
> data address for each task in my workload (which could be 100+ and
> entirely useless).
> Currently this is somewhat involved, since Dwarf doesn't include type
> information for all memops, so we'd have to disassemble and interpret,
> which while tedious is possible.
> However, afaik, Stephane has been working with their tools team to get
> additional DWARF info to make this easier. Stephane, any updates on
> that?
Yeah, that would be interesting to know, I for one, due to the c2c
effort + this other work Stephane mentioned some time ago, moved working
on such a pahole based tool to the backburner, lots of other patches to
review, test, even proof read to then process all the time :-\
- Arnaldo
Powered by blists - more mailing lists