linux-kernel - Re: re-enable Nehalem raw Offcore-Events support

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, 29 Apr 2011 14:01:28 -0400 (EDT)
From:	Vince Weaver <vweaver1@...s.utk.edu>
To:	Ingo Molnar <mingo@...e.hu>
cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Stephane Eranian <eranian@...il.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: re-enable Nehalem raw Offcore-Events support

On Fri, 29 Apr 2011, Ingo Molnar wrote:

> Firstly, one technical problem i have with the raw events ABI method is that it 
> was added in commit e994d7d23a0b ("perf: Fix LLC-* events on Intel 
> Nehalem/Westmere"). The raw ABI bit was done 'under the radar', it was not the 
> declared title of the commit, it was not declared in the changelog either and 
> it was not my intention to offer such an ABI prematurely either - and i noticed 
> those two lines too late - but still in time to not let this slip into v2.6.39.

The initial patches from November seem to make it clear what is being done 
here.  I thought it was pretty obvious to those reviewing those patches 
what was involved.  How would I have known that OFFCORE_RESPONSE support 
was coming if I didn't see the patches obviously float by on linux-kernel?

> Thirdly, and this is my most fundamental objection, i also object to the timing 
> of this offcore raw access ABI, because past experience is that we *really* do 
> not want to allow raw PMU details without *first* having generic abstractions 
> and generic events first.

why?  Can you explain this better?

> The thing is, as far as i can see you and Andi are *still* pushing the failed 
> perfmon and Oprofile ABI and tooling models.

what ABI?  by the way, I hate oprofile and never use it.

perfmon2 and perfctr are very similar to perf_events in that they provide 
lightly massaged access to the MSRs so you can program whatever raw event 
that you like.

It's true that the *userspace* tools (pfmon, iperfex, PAPI) handle things 
differently than perf, but that's a *userspace* API, not a kernel ABI.  
You seem to keep confusing this.

> We put structure, proper abstractions and easy tooling *ahead* of the interests 
> of a small group of people who'd rather prefer a lowlevel, opaque hardware 
> channel so that they do not have to *think* about generalization and also 
> perhaps so they do not have to share their selection of events and analysis 
> methods with others ...

And generalization across platforms (and even across minor chip revisions) 
*doesn't work*.  It lasted maybe a year in PAPI before it was realized to 
be unworkable.  Talk to some people from AMD or Intel if you want.  It's 
not possible to sanely generalize perf counters.  They are too tied to 
hardware quirks.

Vince
vweaver1@...s.utk.edu
--
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/