linux-kernel - Re: [PATCH 2/3] perf: Add support for extra parameters for raw events

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:	Fri, 12 Nov 2010 11:56:08 +0100
From:	Stephane Eranian <eranian@...gle.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Andi Kleen <ak@...ux.intel.com>, linux-kernel@...r.kernel.org,
	fweisbec@...il.com, mingo@...e.hu, acme@...hat.com
Subject: Re: [PATCH 2/3] perf: Add support for extra parameters for raw events

On Fri, Nov 12, 2010 at 11:52 AM, Stephane Eranian <eranian@...gle.com> wrote:
> On Fri, Nov 12, 2010 at 11:48 AM, Andi Kleen <andi@...stfloor.org> wrote:
>>> I don't think you need special syntax. You can simply come up with
>>> the 64-bit raw hex value. corey recently added a small utility to do
>>> this via libpfm4: perf stat -e `evt2raw unhalted_core_cycles:u` ....
>>
>> I added a small patch to perf to read event mappings from a flat mapping file.
>>
>>> > Also, I think we can use the same mechanism to program the
>>> > PEBS-load-latency MSR, right?
>>> >
>>> Yes, we could hardcode the latency the same way.
>>
>> At least right now it would still need a constraint, because only
>> one counter can use it.
>>
>
> True. But there are already contraint tables for PEBS. For instance,
> if I use INST_RETIRED (0x3c) with PEBS, then it cannot use a fixed
> counter. So you can do a constraint for MEM_LOAD_RETIRED:LAT_ABOVE_THRES
> the same way (include the umask).
>
Second thought on this. There is no contraint for the event
MEM_LOAD_RETIRED:LAT_ABOVE_THRES. It can be measured in any
of the 4 generic counters. It's just that it can only be measured once given
the extra MSR would then be shared. One way to implement this constraint
is indeed to mark the event has being able to run only in one counter. That
may be the simplest way to implement this. In that case I would use a
counter which does not have many other constraints, e.g. 3 or 4.
--
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/