---------- Forwarded message ---------- From: stephane eranian <eran...@googlemail.com> Date: Fri, Dec 12, 2008 at 9:59 AM Subject: Re: [patch] Performance Counters for Linux, v3 To: Peter Zijlstra <a.p.zijls...@chello.nl> Cc: Vince Weaver <vi...@deater.net>, Ingo Molnar <mi...@elte.hu>, linux-ker...@vger.kernel.org, Thomas Gleixner <t...@linutronix.de>, Andrew Morton <a...@linux-foundation.org>, Eric Dumazet <da...@cosmosbay.com>, Robert Richter <robert.rich...@amd.com>, Arjan van de Veen <ar...@infradead.org>, Peter Anvin <h...@zytor.com>, Paul Mackerras <pau...@samba.org>, "David S. Miller" <da...@davemloft.net>
Peter, On Fri, Dec 12, 2008 at 9:25 AM, Peter Zijlstra <a.p.zijls...@chello.nl> wrote: > On Thu, 2008-12-11 at 13:02 -0500, Vince Weaver wrote: > >> Perfmon3 works for all of those 60 machines. This new proposal works on a >> 2 out of the 60. > > s/works/is implemented/ > >> Who is going to add support for all of those machines? I've spent a lot >> of developer time getting prefmon going for all of those configurations. >> But why should I help out with this new inferior proposal? It could all >> be another waste of time. > > So much for constructive critisism.. have you tried taking the design to > its limits, if so, where do you see problems? > People have pointed out problems, but you keep forgetting to answer them. For instance, people have pointed out that your design necessarily implies pulling into the kernel the event table for all PMU models out there. This is not just data, this is also complex algorithms to assign events to counters. The constraints between events can be very tricky to solve. If you get this wrong, this leads to silent errors, and that is really bad. Looking at Intel Core, Nehalem, or AMD64 does not reflect the reality of the complexity of this. Paul pointed out earlier the complexity on Power. I can relate to the complexity on Itanium (I implemented all the code in the user level libpfm for them). Read the Itanium PMU description and I hope you'll understand. Events constraints are not going away anytime soon, quite the contrary. Furthermore, event tables are not always correct. In fact, they are always bogus. Event semantics varies between steppings. New events shows up, others get removed. Constraints are discovered later on. If you have all of that in the kernel, it means you'll have to generate a kernel patch each time. Even if that can be encapsulated into a kernel module, you will still have problems. Furthermore, Linux commercial distribution release cycles do not align well with new processor releases. I can boot my RHEL5 kernel on a Nehalem system and it would be nice not to have to wait for a new kernel update to get the full Nehalem PMU event table, so I can program more than the basic 6 architected events of Intel X86. I know the argument about the fact that you'll have a patch with 24h on kernel.org. The problem is that no end-user runs a kernel.org kernel, nobody. Changing the kernel is not an option for many end-users, it may even require re-certifications for many customers. I believe many people would like to see how you plan on addressing those issues. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
