Performance counters?

Posted Jun 12, 2009 11:52 UTC (Fri) by intgr (subscriber, #39733)
Parent article: In brief

> Performance counters. Version 8 of the performance counters patch has been posted.
Curious, I was just investigating performance counters a few hours ago until I found this. How does this relate to the perfctr and perfmon2? (the former, at least, is still maintained)

Performance counters?

Posted Jun 13, 2009 2:32 UTC (Sat) by deater (subscriber, #11746) [Link] (5 responses)

the main difference is perfmon2 is not written by Ingo Molnar, so unfortunately it never had a chance of getting merged. Linux kernel development is sad that way sometimes.

Performance counters?

Posted Jun 18, 2009 14:05 UTC (Thu) by ariveira (guest, #57833) [Link] (4 responses)

+1 to the post above...
Ingo "i will reimplement everything you proposse to me just to piss you off
" Molnar

Performance counters?

Posted Jun 23, 2009 6:23 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

No, he does it because he's a hacker. We reinvent wheels for the fun of
it. It's what we do.

Perhaps this is not praiseworthy, but it is a universal trait.

Performance counters?

Posted Jun 23, 2009 11:08 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

one thing you have to remember in kernel development is that people really want to see the minimal solution to the problem.

people who go off and do their own thing for a while, and then come to the kernel tend to have complex solutions, and do a very poor job of explaining why they are complex.

as a result it's not uncommon to see someone else take the basic idea, implement a simple version, and then evolve it to add capabilities and end up with something very similar to what was initially proposed. but because the added complications are seen and discussed, the re-worked version ends up being accepted (it's also not uncommon to see it accepted while it's simpler, and then grows over time)

if the people proposing these new systems presented the progress and logic, not just the final result, they would probably be in better shape.

Keep in mind that there is a chance that someone will disagree with a decision made early in your development, which may invalidate a lot of work done after that point. so you are far better off communicating early so that you don't waste time like this.

Performance counters?

Posted Jun 24, 2009 11:18 UTC (Wed) by etienne_lorrain@yahoo.fr (guest, #38022) [Link] (1 responses)

Ever seen this pattern:
- you produce a patch to a non working part of the kernel, and work quite hard to get that (small) part to work in every condition you can think of.
- you send that patch to the list.
- the patch is modified and integrated into the official kernel before you can even see the modification.
- the modification of the patch broke a special configuration, that is maybe why the patch was more complex than needed in the eyes of the maintainer of the subsystem.
- people complain that the kernel with your patch is not always working, and the kernel switch is marked with a "DANGEROUS" comment.

Anyway, it is old and completely forgotten story (even by me)...

Performance counters?

Posted Jun 27, 2009 0:23 UTC (Sat) by dlang (guest, #313) [Link]

there is a significant amount of time between the patch getting integrated and a release of the kernel. during that time you should be testing that the resulting kernel works in the cases that you tested, especially if there were modifications to it.

you don't even need to use git for this, there are the -rc releases and nightly -git tarballs available.

Performance counters?

Posted Jun 15, 2009 22:11 UTC (Mon) by anton (subscriber, #25547) [Link]

How does this relate to the perfctr and perfmon2?

I second that question.

(the former, at least, is still maintained)

And also used. Perfctr is relatively easy to install, works on more platforms than the patch mentioned here (e.g., perfctr works on my iBook G4 (PPC 7447A), and I have scripts that use it. Lots of reasons to stick with it.