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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 12 Dec 2008 13:18:32 -0500 (EST)
From:	Vince Weaver <vince@...ter.net>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephane Eranian <eranian@...glemail.com>,
	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

On Fri, 12 Dec 2008, Peter Zijlstra wrote:
> On Thu, 2008-12-11 at 13:02 -0500, Vince Weaver wrote:
>
>> Perfmon3 works for all of those 60 machines.  This new proposal works on a
>> 2 out of the 60.
>
> s/works/is implemented/

Once you "implement" the new solution for all the machines I listed, it's 
going to be just as bad, if not worse, than current perfmon3.

> So much for constructive critisism.. have you tried taking the design to
> its limits, if so, where do you see problems?

I have a currently working solution in perfmon3.
I need a pretty strong reason to abandon that.

> I read the above as: I invested a lot of time in something of dubious
> statue (out of tree patch), and now expect it to be merged because I
> have invested in it.

perfmon has been around for years.  It's even been in the kernel (in 
Itanium form) for years.  The perfmon patchset has been posted numerous 
time for reviews to the linux-kernel list.  It's not like perfmon was some 
sort of secret project sprung on the world last-minute.

I know the way the Linux kernel development works.  If some other 
performance monitoring implementation does get merged, I will cope and 
move on.  I'm just trying to help avoid a costly mistake.

>> Also, my primary method of using counters is total aggregate count for a
>> single user-space process.
>
> Process, as in single thread, or multi-threaded? I'll assume
> single-thread.

No.  Multi-thread too.

> 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?

No.

I do not use PAPI.  PAPI only supports a small subset of counters.

What is needed is a tool for accessing _all_ performance counters on 
various machines.

What is _not_ needed is pushing PAPI into kernel space.

> The proposal allows for you to specify raw hardware events, so you can
> just totally ignore this part of the abstraction.

If you can do raw events, then that's enough.  There's no need to put some 
sort of abstraction level into the kernel.  That way lies madness if 
you've ever looked at any code that tries to do it.

As others have suggested, check out the P4 PMU documentation.

Vince
--
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/