linux-mips
[Top] [All Lists]

Re: [PATCH 1/4] MIPS/Perf-events: update the map of unsupported events f

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH 1/4] MIPS/Perf-events: update the map of unsupported events for 74K
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Wed, 09 Nov 2011 23:00:28 +0100
Cc: Deng-Cheng Zhu <dczhu@mips.com>, linux-mips@linux-mips.org, Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@elte.hu>, Arnaldo Carvalho de Melo <acme@ghostprotocols.net>, David Daney <david.daney@cavium.com>
In-reply-to: <20111109204020.GB13280@linux-mips.org>
References: <1319453762-12962-1-git-send-email-dczhu@mips.com> <1319453762-12962-2-git-send-email-dczhu@mips.com> <20111109204020.GB13280@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 2011-11-09 at 20:40 +0000, Ralf Baechle wrote:
> On Mon, Oct 24, 2011 at 06:55:59PM +0800, Deng-Cheng Zhu wrote:
> 
> > Update the raw event info for 74K according to the latest document.
> 
> > +/*
> > + * MIPS document MD00519 (MIPS32(r) 74K(tm) Processor Core Family Software
> > + * User's Manual, Revision 01.05)
> > + */
> >  #define IS_UNSUPPORTED_74K_EVENT(r, b)                                     
> > \
> > -   ((r) == 5 || ((r) >= 135 && (r) <= 137) ||                      \
> > -    ((b) >= 10 && (b) <= 12) || (b) == 22 || (b) == 27 ||          \
> > -    (b) == 33 || (b) == 34 || ((b) >= 47 && (b) <= 49) ||          \
> > -    (r) == 178 || (b) == 55 || (b) == 57 || (b) == 60 ||           \
> > -    (b) == 61 || (r) == 62 || (r) == 191 ||                        \
> > -    ((b) >= 64 && (b) <= 127))
> > +   ((r) == 5 || (r) == 135 || ((b) >= 10 && (b) <= 12) ||          \
> > +    (b) == 27 || (b) == 33 || (b) == 34 || (b) == 47 ||            \
> > +    (b) == 48 || (r) == 178 || (r) == 187 || (b) == 60 ||          \
> > +    (b) == 61 || (r) == 191 || (r) == 71 || (r) == 72 ||           \
> > +    (b) == 73 || ((b) >= 77 && (b) <= 127))
> 
> I wonder if such detailed checking of the performance counter
> event numbers is really needed?  As long as feeding an bad number only
> results in undefined counts of the performance counters I think we may
> be better of by not checking the event numbers in detail.  Afair there
> are MIPS licensee who have modified the counters to count extra events
> so I sense some madness in that direction.

Right, we don't do much sanity checking on x86 either, all we do check
are privilege bits, the rest we directly feed to the hardware. This all
works as long as the hardware doesn't in fact fall over or worse of
course. 

On x86 it means you can program events that are outside those specified
in the SDM, some actually count, although outside of specific hardware
team for that chip I doubt there's anybody on the planet who can tell
you what ;-)

Not counting or counter utter crap is fine, that's what you get for
passing in random numbers.

<Prev in Thread] Current Thread [Next in Thread>