linux-kernel - Re: [patch] Performance Counters for Linux, v3

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 Dec 2008 09:35:43 +0100
From:	"stephane eranian" <eranian@...glemail.com>
To:	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Cc:	"Vince Weaver" <vince@...ter.net>, "Ingo Molnar" <mingo@...e.hu>,
	linux-kernel@...r.kernel.org,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Eric Dumazet" <dada1@...mosbay.com>,
	"Robert Richter" <robert.richter@....com>,
	"Arjan van de Veen" <arjan@...radead.org>,
	"Peter Anvin" <hpa@...or.com>, "Paul Mackerras" <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [patch] Performance Counters for Linux, v3

Peter,

On Fri, Dec 12, 2008 at 9:25 AM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>> > +   /*
>> > +    * Common hardware events, generalized by the kernel:
>> > +    */
>> > +   PERF_COUNT_CYCLES               =  0,
>> > +   PERF_COUNT_INSTRUCTIONS         =  1,
>> > +   PERF_COUNT_CACHE_REFERENCES     =  2,
>> > +   PERF_COUNT_CACHE_MISSES         =  3,
>> > +   PERF_COUNT_BRANCH_INSTRUCTIONS  =  4,
>> > +   PERF_COUNT_BRANCH_MISSES        =  5,
>>
>> Many machines do not support these counts.  For example, Niagara T1 does
>> not have a CYCLES count.  And good luck if you think you can easily come
>> up with something meaningful for the various kind of CACHE_MISSES on the
>> Pentium 4.  Also, the Pentium D has various flavors of retired instruction
>> count with slightly different semantics.  This kind of abstraction should
>> be done in userspace.
>
> I'll argue to disagree, sure such events might not be supported by any
> particular hardware implementation - but the fact that PAPI gives a list
> of 'common' events means that they are, well, common. So unifying them
> between those archs that do implement them seems like a sane choice, no?
>
> For those archs that do not support it, it will just fail to open. No
> harm done.
>
> The proposal allows for you to specify raw hardware events, so you can
> just totally ignore this part of the abstraction.
>
I believe the cache related events do not belong in here. There is no definition
for them. You don't know what cache miss level, what kind of access. You cannot
do this even on Intel Core processors.
--
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/