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, 5 Dec 2008 11:22:11 +1100 From: Paul Mackerras <paulus@...ba.org> To: Thomas Gleixner <tglx@...utronix.de> Cc: LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, Ingo Molnar <mingo@...e.hu>, Stephane Eranian <eranian@...glemail.com>, Eric Dumazet <dada1@...mosbay.com>, Robert Richter <robert.richter@....com>, Arjan van de Veen <arjan@...radead.org>, Peter Anvin <hpa@...or.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Steven Rostedt <rostedt@...dmis.org>, David Miller <davem@...emloft.net> Subject: Re: [patch 0/3] [Announcement] Performance Counters for Linux Thomas Gleixner writes: > We'd like to announce a brand new implementation of performance counter > support for Linux. It is a very simple and extensible design that has the > potential to implement the full range of features we would expect from such > a subsystem. Looks like the sort of thing I was thinking about a year or so ago when I was trying to come up with a simpler API than perfmon2. However, it turned out that my design, and I believe yours too, can't do some things that users really want to do with performance counters. One thing that this sort of thing can't do is to get values from multiple counters that correlate with each other. For instance, we would often want to count, say, L2 cache misses and instructions completed at the same time, and be able to read both counters at very close to the same time, so that we can measure average L2 cache misses per instruction completed, which is useful. Another problem is that this abstraction provides no way to deal with interrelationships between counters. For example, on PowerPC it is common to have a facility where one counter overflowing can cause all the other counters to freeze. I don't see this abstraction providing any way to handle that. It looks to me that your new API will be unworkable for real performance measurement and tuning, just like mine ended up being. :) Paul. -- 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