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

[Ingo Molnar]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Thu, Jul 09, 2015 at 11:26:56AM +0200, Ingo Molnar wrote:
> > 
> > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/