Perfcounters added to the mainline
Posted Jul 3, 2009 23:09 UTC (Fri) by mingo
In reply to: Perfcounters added to the mainline
Parent article: Perfcounters added to the mainline
* There is still some lingering bitterness about how Ingo took over perfcounters [...]
(Just a question - from your post i gather that you are an (ex?) perfmon developer. If yes then i'm not surprised that you feel bitter about it - still it would have been nice had you openly disclosed your direct involvement and bias in this matter.)
The thing is, perfmon, despite being available for years, never achieved any measurable usage amongst kernel developers. You can check this yourself, just type: "git log --grep=pfmon" in an upstream kernel repository. It comes up empty: no-one ever found it important to mention pfmon in an upstream kernel changelog. Not one commit out of more than 150,000 upstream kernel commits ever mentioned that pfmon was used to measure something or to solve a problem.
The reason? I cannot speak for other kernel developers but i have my guesses: i tried it, and the thing is close to unusable to kernel developers. It has way too much overhead to measure workloads with lots of tasks and lots of overhead. It relies on a fat and quirky library and takes way too much effort to install and use. Its sampling (profiling) does not read ELF symbols as far as i could see.
perfmon had many other design problems as well (not directly visible to users) - i explained the reasons in the (many) posts i wrote about perfcounters in the past ~6 months. The main failure was that it tried to abstract on a way too low level, on an almost register basis - without the kernel having any knowledge about the structure of the hardware it abstracts away.
That design choice is lethal: it has shut off many interesting capabilities that perfcounters offers here and today: inherited counters, software counters, transparent workload monitoring, nested counters, various context-switch performance optimizations, etc. etc.
to post comments)