linux-kernel - Re: [Patch v1 04/10] perf/x86: add memory profiling via PEBS Load Latency

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:	Mon, 29 Oct 2012 21:39:26 +0100
From:	Stephane Eranian <eranian@...gle.com>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Jiri Olsa <jolsa@...hat.com>
Subject: Re: [Patch v1 04/10] perf/x86: add memory profiling via PEBS Load Latency

On Mon, Oct 29, 2012 at 8:42 PM, Andi Kleen <ak@...ux.intel.com> wrote:
>> +
>> +struct attribute *nhm_events_attrs[] = {
>> +     EVENT_PTR(CPU_CYCLES),
>> +     EVENT_PTR(INSTRUCTIONS),
>> +     EVENT_PTR(CACHE_REFERENCES),
>> +     EVENT_PTR(CACHE_MISSES),
>> +     EVENT_PTR(BRANCH_INSTRUCTIONS),
>> +     EVENT_PTR(BRANCH_MISSES),
>> +     EVENT_PTR(BUS_CYCLES),
>> +     EVENT_PTR(STALLED_CYCLES_FRONTEND),
>> +     EVENT_PTR(STALLED_CYCLES_BACKEND),
>> +     EVENT_PTR(REF_CPU_CYCLES),
>> +     EVENT_PTR(mem_ld_nhm),
>> +     NULL,
>> +};
>
> I thought Jiri's patch already exports all the generic ones?
>
> Why do you need to replace the whole table?
>
Because I am extending them with one or two events based on cpu
model. That was the easiest way of doing this instead of playing
some kind of malloc+copy trick.

> BTW I still think my approach in the v4 Haswell patchkit
> is simpler and didn't rely on hardcoding these events.
>
I don't care about those events. As I found out, they are not even
used by perf because they are all hardcoded and that's what gets
used. I assume they are exposed for reference only. I don't object
to that. But I think the right mechanism would be one where you
can add events at boot time based on CPU model. It could be used
to add the common events as well in the common part of the init
code.
--
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/