linux-kernel - Re: [PATCH 1/1] perf tools: Add missing user space support for config1/config2

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]

Message-ID: <1303809958.20212.219.camel@twins>
Date:	Tue, 26 Apr 2011 11:25:58 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Vince Weaver <vweaver1@...s.utk.edu>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
	Stephane Eranian <eranian@...il.com>,
	Lin Ming <ming.m.lin@...el.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/1] perf tools: Add missing user space support for
 config1/config2

On Mon, 2011-04-25 at 13:12 -0400, Vince Weaver wrote:
> On Fri, 22 Apr 2011, Ingo Molnar wrote:
> 
> > But this kind of usability is absolutely unacceptable - users should not
> > be expected to type in magic, CPU and model specific incantations to get
> > access to useful hardware functionality.
> 
> That's why people use libpfm4.  or PAPI.  And they do.

And how is typing in hex numbers different from typing in model specific
event names? All the same to me, you still need to understand your micro
architecture very thoroughly and read the SDMs.

PAPI actually has 'generalized' events, but I guess you're going to tell
me nobody uses those since they're not useful.

> Current PAPI snapshots support offcore response on recent git kernels.
> With full names, no hex values, thanks to libpfm4.
> 
> All the world is not perf.

I know, all the world is interested in investing tons of time learning
about their one architecture and extract the last few percent of
performance.

And that is fine for those few people who can afford it, but generally
optimizing for a single specific platform isn't cost effective.

I looks like you're all so stuck in your HPC/lowlevel way of things
you're not even realizing there's much more to be gained by providing
easy and useful tools to the general public, stuff that works similarly
across architectures.

> > The proper solution is to expose useful offcore functionality via
> > generalized events - that way users do not have to care which specific
> > CPU model they are using, they can use the conceptual event and not some
> > model specific quirky hexa number.
> 
> No no no no.
> 
> Blocking access to raw events is the wrong idea.  If anything, the whole 
> "generic events" thing in the kernel should be ditched.  Wrong events are 
> used at times (see AMD branch events a few releases back, now Nehalem 
> cache events).  This all belongs in userspace, as was pointed out at the 
> start.  The kernel has no business telling users which perf events are 
> interesting, or limiting them!  What is this, windows?

The kernel has no place scheduling pmcs either I expect, or scheduling
tasks for that matter.

We all know you don't believe in upgrading kernels or in kernels very
much at all.

> If you do block access to any raw events, we're going to have to start 
> recommending people ditch perf_events and start patching the kernel with 
> perfctr again.  We already do for P4/netburst users, as Pentium 4 support 
> is currently hosed due to NMI event conflicts.

Very constructive attitude, instead of helping you simply subvert and
route around, thanks man! 

You could of course a) simply disable the NMI watchdog, or b) improve
the space-heater (aka. P4) PMU implementation to use alternative
encodings -- from what I understood the problem with P4 is that there's
multiple ways to encode the same event and currently if you take one it
doesn't try others.

> Also with perfctr it's much easier to get low-latency access to the 
> counters.  See:
>   http://web.eecs.utk.edu/~vweaver1/projects/papi-cost/

And why is that? is that the lack of userspace rdpmc? That should be
possible with perf, powerpc actually does that already. Various people
mentioned wanting to make this work on x86 but I've yet to see a patch.
--
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/