linux-kernel - Re: [PATCH 1/4] perf: Add memory load/store events generic code

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, 05 Jul 2011 14:03:38 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Lin Ming <ming.m.lin@...el.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
	Stephane Eranian <eranian@...gle.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Anton Blanchard <anton@...ba.org>, paulus <paulus@...ba.org>
Subject: Re: [PATCH 1/4] perf: Add memory load/store events generic code

On Mon, 2011-07-04 at 10:44 +0200, Peter Zijlstra wrote:
> On Mon, 2011-07-04 at 10:33 +0200, Peter Zijlstra wrote:
> > On Mon, 2011-07-04 at 08:02 +0000, Lin Ming wrote:
> > > +/*
> > > + * Memory load operation info encoding
> > > + */
> > > +
> > > +/* Bits(0-1) {L1, L2, L3, RAM} or {unknown, IO, uncached, reserved}
> > > */
> > > +#define MEM_LOAD_L1                    0x00
> > > +#define MEM_LOAD_L2                    0x01
> > > +#define MEM_LOAD_L3                    0x02
> > > +#define MEM_LOAD_RAM                   0x03
> > > +#define MEM_LOAD_UNKNOWN               0x00
> > > +#define MEM_LOAD_IO                    0x01
> > > +#define MEM_LOAD_UNCACHED              0x02
> > > +#define MEM_LOAD_RESERVED              0x03
> > > +
> > > +/* Bits(2-3) {toggle, snoop, local, remote} */
> > > +#define MEM_LOAD_TOGGLE                        (0x00 << 2)
> > > +#define MEM_LOAD_SNOOP                 (0x01 << 2)
> > > +#define MEM_LOAD_LOCAL                 (0x02 << 2)
> > > +#define MEM_LOAD_REMOTE                        (0x03 << 2)
> > > +
> > > +/* Bits(4-5) {modified, exclusive, shared, invalid} */
> > > +#define MEM_LOAD_MODIFIED              (0x00 << 4)
> > > +#define MEM_LOAD_EXCLUSIVE             (0x01 << 4)
> > > +#define MEM_LOAD_SHARED                        (0x02 << 4)
> > > +#define MEM_LOAD_INVALID               (0x03 << 4) 
> > 
> > Did anybody check with the other PMUs that have similar features like
> > PowerPC and possibly IA64?
> > 
> > I keep mentioning this, nobody seems interested.
> 
> Anton, Paulus, IIRC PowerPC had some sort of Data-Source indication,
> would you have some docs available on the PowerPC PMU?

Going through
http://www.power.org/resources/downloads/PowerISA_V2.06B_V2_PUBLIC.pdf

Book III-S, Appendix B

I can only find the SDAR thing (which I assume is what PERF_SAMPLE_DATA
uses) but no mention of extra bits describing where the data was sourced
from. For some reason I had the impression PPC64 had the capability to
tell if a load/store was from/to L1/2/3/DRAM etc.

Now since the above document is in fact not an exhaustive spec of a
particular chip but more an outline of what a regular ppc64 chip should
have, with lots of room for implementation specific extensions it
doesn't say much at all.

So do you know of such a feature for PPC64 and if so, where's the
docs? :-)
--
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/