linux-kernel - Re: [RFC PATCH] perf: Provide status of known PMUs

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 9 Jul 2015 14:32:05 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Adrian Hunter <adrian.hunter@...el.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Vince Weaver <vincent.weaver@...ne.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Jiri Olsa <jolsa@...hat.com>,
	Stephane Eranian <eranian@...gle.com>,
	Borislav Petkov <bp@...e.de>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [RFC PATCH] perf: Provide status of known PMUs


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Thu, Jul 09, 2015 at 11:26:56AM +0200, Ingo Molnar wrote:
> > 
> > * Peter Zijlstra <peterz@...radead.org> 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.
> > 
> > Absolutely x86 should list them as well - from a user POV arch dependent 
> > tooling sucks in general. There's nothing more annoying than trying to figure 
> > out why a particular tool does not work.
> 
> But why would the tool care?

Yeah, but the user cares. If I type something like:

   perf record -e bts// --per-thread sleep 1

... and it does not work, I expect the tool to print something informative and 
productive, for example one of these:

   perf record error: The 'bts' PMU is not available, because this architecture does not support it
   perf record error: The 'bts' PMU is not available, because the CPU does not support it
   perf record error: The 'bts' PMU is not available, because its driver is not built into the kernel

Because if it's the wrong architecture or CPU, I look for a box with the right 
one, if it's simply the kernel not having the necessary PMU driver then I'll boot 
a kernel with it enabled.

Thanks,

	Ingo
--
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/