linux-kernel - Re: [PATCH 00/21] perf, c2c: Add new tool to analyze cacheline contention on NUMA systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Feb 2014 08:50:13 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Stephane Eranian <eranian@...gle.com>,
	Don Zickus <dzickus@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jiri Olsa <jolsa@...hat.com>, Joe Mario <jmario@...hat.com>,
	Richard Fowles <fowles@...each.com>
Subject: Re: [PATCH 00/21] perf, c2c: Add new tool to analyze cacheline
 contention on NUMA systems

Em Tue, Feb 11, 2014 at 12:14:21PM +0100, Peter Zijlstra escreveu:
> On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
> > Assuming you can decode and get the info about the base registers used,
> > you'd have to do this for each arch with load/store sampling capabilities.
> > this is painful compared to getting the portable info from dwarf directly.
 
> But its useful now, as compared to whenever GCC gets around to
> implementing more dwarves and that GCC getting used widely enough to
> actually rely on it.
 
> All you need for the decode is a disassembler, and every arch should
> already have multiple of those. Should be easy to reuse one, right?

Yeah, I never got around to actually try to implement this, but my
feeling was that all the bits and pieces were there already:

1) the precise IP for the instruction, that disassembled would tell
which registers were being operated on, or memory that we would "reverse
map" to a register

2) DWARF expression locations that allows us to go from registers to a
variable/parameter and thus to a type

3) PERF_SAMPLE_REGS_USER (from a quick look, why do we have "USER" in
it? Jiri?)

4) libunwind have register maps for various arches, so probably
something there could be reused here as well (Jiri?)

Get that and generate a series of (type,offset) tuples for the samples
and get pahole to highlight the members with different colours, just
like 'annotate' does with source code/asm.

That way we would reuse 'pahole' in much the same way as we reuse
'objdump'. Give some more time to revisit the libdwarves APIs and then
we could use it directly on perf or perhaps extract just what is needed
and merge into the kernel sources.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/