Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751045AbbGIJdZ (ORCPT ); Thu, 9 Jul 2015 05:33:25 -0400 Received: from mga09.intel.com ([134.134.136.24]:41135 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750943AbbGIJdS (ORCPT ); Thu, 9 Jul 2015 05:33:18 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,439,1432623600"; d="scan'208";a="758957996" Message-ID: <559E3F36.5020900@intel.com> Date: Thu, 09 Jul 2015 12:30:30 +0300 From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Zijlstra CC: Ingo Molnar , Arnaldo Carvalho de Melo , Andy Lutomirski , Vince Weaver , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org, Jiri Olsa , Stephane Eranian , Borislav Petkov , Alexander Shishkin , Andi Kleen Subject: Re: [RFC PATCH] perf: Provide status of known PMUs References: <1436428080-3098-1-git-send-email-adrian.hunter@intel.com> <20150709085022.GB2859@worktop.programming.kicks-ass.net> In-Reply-To: <20150709085022.GB2859@worktop.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2063 Lines: 64 On 09/07/15 11:50, Peter Zijlstra wrote: > On Thu, Jul 09, 2015 at 10:48:00AM +0300, Adrian Hunter wrote: >> Known PMUs may not be present for various reasons. >> Provide a way for the user to know what the reason >> is. > > Not a bad idea, but I do wonder where we should draw the line on what is > 'known'. The patch as proposed will have bts/pt listed as 'known' for > every arch out there. > > By that logic, x86 should list the ppc/sparc/mips/arm/etc.. PMUs as > known and wrong_arch too, which might be a tad excessive. > > Can we limit it to PMUs for which we've (attempted to) load the drivers? > That would obviously make a few of your status bits redundant, but then > you've not explained why we're interested in it. > >> Supported >> Driver error >> Driver not loaded >> Not supported by hardware >> Wrong vendor >> Unknown status > > There would work. > >> Driver not in kernel config >> Not supported by kernel >> Wrong architecture > > These will be hard, for if we don't load the driver we don't 'know' of > them. Are they that hard? The architecture one is done by perf core at the moment when the initial status is defined e.g. #if defined(CONFIG_X86) #define PERF_PMU_STATUS_ARCH_X86 PERF_PMU_STATUS_UNKNOWN #else #define PERF_PMU_STATUS_ARCH_X86 PERF_PMU_STATUS_WRONG_ARCH #endif static struct known_pmu known_pmus[] = { KNOWN_PMU("intel_pt", "Intel", PERF_PMU_STATUS_ARCH_X86), KNOWN_PMU("intel_bts", "Intel", PERF_PMU_STATUS_ARCH_X86), KNOWN_PMU(NULL, NULL, 0), }; For config and module the arch perf init code can check e.g. #if !defined(CONFIG_MY_PMU) && !defined(CONFIG_MY_PMU_MODULE) perf_pmu_update_status("my_pmu", PERF_PMU_STATUS_NOT_CONFIG, NULL); #elif defined(CONFIG_MY_PMU_MODULE) perf_pmu_update_status("my_pmu", PERF_PMU_STATUS_NOT_LOADED, NULL); #endif -- 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/