linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"arc-linux-dev@synopsys.com" <arc-linux-dev@synopsys.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Vineet Gupta <Vineet.Gupta1@synopsys.com>
Subject: Re: [PATCH 1/8] ARC: perf: support RAW events
Date: Wed, 17 Jun 2015 15:33:58 +0200	[thread overview]
Message-ID: <20150617133358.GR3644@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <4881796E12491D4BB15146FE0209CE64656C9E81@DE02WEMBXB.internal.synopsys.com>

On Tue, Jun 16, 2015 at 11:45:52AM +0000, Alexey Brodkin wrote:
> First let me clarify a bit how we deal with hardware events in ARC cores.
> 
>  a) ARC core may have an arbitrary set of hardware events built-in.
>  Upon creation of new ASIC project hardware engineer may select which
>  events will be exposed to event counters. For example only a very
>  basic set of events could be made available like "cycles running",
>  "committed instructions" etc. Or much more extensive set of events
>  could be exposed to event counters including very specific
>  architectural events like separate "committed 16-bit instructions"
>  and "committed 32-bit instructions".
> 
>  b) Also list of all possible events is much longer than 32 or 64
>  entries that makes it impossible to map all possible events as a
>  separate bits in 32- or 64-bit word.
> 
> Having both [a] and [b] in mind we implemented the following scheme of working with HW events.
> 
>  [1] Hardware may report a list of all event that could be counted in this particular CPU.
> 
>  [2] That lists consists of short ASCII names (up to 8 characters) for each event.
> 
>  [3] Index of the particular even in the list is used to setup an event counter.
> 
> See corresponding code for it here:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/kernel/perf_event.c#n308
> 
> I.e. if we need to count "xxx" event and we know it's 10th in the list
> of events we set event counter to count event #10, see
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/kernel/perf_event.c#n151
> 
> With generic hardware events we don't do any visible trickery as you
> may see from code by the link above simply because we know how to
> translate PERF_COUNT_HW_CPU_CYCLES to the index of corresponding
> event, see:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/include/asm/perf_event.h#n87
> 
> But in case of raw events we need to set a counter with index of a
> particular event. For example we need to count "myevnt0" events. For
> this we need first to find-out what's an index in events list of
> "myevnt0" event and then set event counter to count event #x.
> 
> Even though in theory we may set raw even passing an index of desired
> event 

That is what I was thinking of, until I read:

> but given my explanation above each particular CPU may have the
> same event with different index in events list.

...

> Fortunately there's already a patch series floating in LKML that
> attempts to simplify usage of architecture-specific events, see
> http://www.spinics.net/lists/kernel/msg2010232.html

So you _can_ know a priory in which order the events are for a
particular CPU ? Say through /proc/cpuinfo.

I would much prefer the raw thing to remain a number; it puts you in
pretty much the same place as most other archs, including x86.

On x86 we have a huge event list (see the Intel SDM for example) and the
only way to access those (currently, without the above patch series) is
to look in the PDF under the right model and enter the numbers by hand.


The only way in which your hardware appears different is in that it
seems to include these names in hardware; which to me seems a waste of
perfectly fine silicon, but hey not my call.


  reply	other threads:[~2015-06-17 13:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-09 12:19 [PATCH 0/8] ARCv2 port to Linux - (C) perf Vineet Gupta
2015-06-09 12:19 ` [PATCH 1/8] ARC: perf: support RAW events Vineet Gupta
2015-06-15 15:30   ` Peter Zijlstra
2015-06-16 11:45     ` Alexey Brodkin
2015-06-17 13:33       ` Peter Zijlstra [this message]
2015-06-17 14:10         ` Vineet Gupta
2015-06-22 14:41           ` Peter Zijlstra
2015-06-23 12:20             ` Vineet Gupta
2015-06-17 12:32     ` Vineet Gupta
2015-06-09 12:19 ` [PATCH 2/8] ARC: perf: cap the number of counters to hardware max of 32 Vineet Gupta
2015-06-09 12:19 ` [PATCH 3/8] ARCv2: perf: implement "event_set_period" for future use with interrupts Vineet Gupta
2015-06-15 15:38   ` Peter Zijlstra
2015-06-22 15:26     ` Alexey Brodkin
2015-06-09 12:19 ` [PATCH 4/8] ARCv2: perf: Support sampling events using overflow interrupts Vineet Gupta
2015-06-15 15:48   ` Peter Zijlstra
2015-06-22 15:57     ` Alexey Brodkin
2015-06-15 16:25   ` Peter Zijlstra
2015-06-16  5:37     ` Vineet Gupta
2015-06-16  9:07       ` Peter Zijlstra
2015-06-16  9:33         ` Vineet Gupta
2015-06-17 11:48         ` Vineet Gupta
2015-06-17 12:44           ` Peter Zijlstra
2015-06-09 12:19 ` [PATCH 5/8] ARCv2: perf: set usable max period as a half of real max period Vineet Gupta
2015-06-09 12:19 ` [PATCH 6/8] ARCv2: perf: implement exclusion of event counting in user or kernel mode Vineet Gupta
2015-06-09 12:19 ` [PATCH 7/8] ARCv2: perf: SMP support Vineet Gupta
2015-06-09 12:19 ` [PATCH 8/8] ARCv2: perf: Finally introduce HS perf unit Vineet Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150617133358.GR3644@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=Vineet.Gupta1@synopsys.com \
    --cc=acme@kernel.org \
    --cc=arc-linux-dev@synopsys.com \
    --cc=arnd@arndb.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).