Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753538Ab1DVT5k (ORCPT ); Fri, 22 Apr 2011 15:57:40 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:41571 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752736Ab1DVT5j (ORCPT ); Fri, 22 Apr 2011 15:57:39 -0400 Date: Fri, 22 Apr 2011 21:57:20 +0200 From: Ingo Molnar To: Andi Kleen Cc: Stephane Eranian , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Peter Zijlstra , Lin Ming , Arnaldo Carvalho de Melo , Thomas Gleixner , Peter Zijlstra , eranian@gmail.com, Arun Sharma , Linus Torvalds , Andrew Morton Subject: Re: [generalized cache events] Re: [PATCH 1/1] perf tools: Add missing user space support for config1/config2 Message-ID: <20110422195720.GB17583@elte.hu> References: <20110422092322.GA1948@elte.hu> <20110422105211.GB1948@elte.hu> <20110422165120.GA16607@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110422165120.GA16607@tassilo.jf.intel.com> User-Agent: Mutt/1.5.20 (2009-08-17) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1224 Lines: 33 * Andi Kleen wrote: > > Once you have clear and precise definition, then we can look at the actual > > events and figure out a mapping. > > It's unclear this can be even done. Linux runs on a wide variety of micro > architectures, with all kinds of cache architectures. > > Micro architectures are so different. I suspect a "generic" definition would > need to be so vague as to be useless. Not really. I gave a very specific example which solved a common and real problem, using L1-loads and L1-load-misses events. > This in general seems to be the problem of the current cache events. > > Overall for any interesting analysis you need to go CPU specific. Abstracted > performance analysis is a contradiction in terms. Nothing of what i did in that example was CPU or microarchitecture specific. Really, you are making this more complex than it really is. Just check the cache profiling example i gave, it works just fine today. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/