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
| ||
|
Date: Fri, 12 Dec 2008 09:59:56 +0100 From: "stephane eranian" <eranian@...glemail.com> To: "Peter Zijlstra" <a.p.zijlstra@...llo.nl> Cc: "Vince Weaver" <vince@...ter.net>, "Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org, "Thomas Gleixner" <tglx@...utronix.de>, "Andrew Morton" <akpm@...ux-foundation.org>, "Eric Dumazet" <dada1@...mosbay.com>, "Robert Richter" <robert.richter@....com>, "Arjan van de Veen" <arjan@...radead.org>, "Peter Anvin" <hpa@...or.com>, "Paul Mackerras" <paulus@...ba.org>, "David S. Miller" <davem@...emloft.net> Subject: Re: [patch] Performance Counters for Linux, v3 Peter, On Fri, Dec 12, 2008 at 9:25 AM, Peter Zijlstra <a.p.zijlstra@...llo.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. -- 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/
Powered by blists - more mailing lists