* I personally think the abstraction they chose of having "common" counters hard-wired in the kernel to be a bad one, because as they are already finding out every chip and chip revision has different counters with different issues. perfmon2 took the saner route to do this in user-space; once 2.6.31 is released the ABI is frozen and we're going to be stuck with this.
Not really. The days of weird x86 PMUs changing with every CPU model are gone, fortunately.
The AMD PMU programming low level details have stayed pretty stable since around the K7 or so - for many years.
Intel has also introduced 'architectural performance monitoring' starting with Core2 (and has extended it in Corei7) which too is a future-proof method.
Also, even assuming weird PMUs, the perfcounters ABI does not hard-code low level details like that. Proof of this is in the fact that most Power CPUs are supported by perfcounters - which all have PMUs that are wildly different from x86 PMUs.
The reason perfcounters abstracts away common events is utility: it is convenient to tools to use a 'cycles' or a 'branches executed' events regardless of which CPU model they are running on. perfmon/pfmon, despite many years of development, never achieved this kind of basic utility.
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds