public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Mischa Jonker <Mischa.Jonker@synopsys.com>
Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARC: Add perf support
Date: Thu, 29 Aug 2013 08:41:24 +0200	[thread overview]
Message-ID: <20130829064124.GB27322@gmail.com> (raw)
In-Reply-To: <1377720814-2779-1-git-send-email-mjonker@synopsys.com>


* Mischa Jonker <Mischa.Jonker@synopsys.com> wrote:

> +/* The "generalized" performance events seem to really be a copy
> +   of the available events on x86 processors; the mapping to ARC
> +   events is not always possible 1-to-1. Fortunately, there doesn't
> +   seem to be an exact definition for these events, so we can cheat
> +   a bit where necessary */
> +static const char * const arc_pmu_ev_hw_map[] = {
> +	/* cycles not in halted state */
> +	[PERF_COUNT_HW_CPU_CYCLES] = "crun",
> +	/* reference cycles not in halted state; also "crun" as we don't
> +	   do Dynamic Voltage/Frequency Scaling (yet) */
> +	[PERF_COUNT_HW_REF_CPU_CYCLES] = "crun",
> +	/* Unclear what this means, Intel uses 0x013c, which according to
> +	   their datasheet means "unhalted reference cycles". Don't ask
> +	   me what the difference is with PERF_COUNT_HW_REF_CPU_CYCLES */
> +	[PERF_COUNT_HW_BUS_CYCLES] = "crun",
> +	[PERF_COUNT_HW_INSTRUCTIONS] = "iall",
> +	[PERF_COUNT_HW_BRANCH_MISSES] = "bpfail",
> +	[PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = "ijmp",
> +	/* ARC can either measure stalls per pipeline stage, or all stalls
> +	   combined; for now we assign all stalls to STALLED_CYCLES_BACKEND
> +	   and all pipeline flushes (e.g. caused by mispredicts, etc.) to
> +	   STALLED_CYCLES_FRONTEND.
> +
> +	   We could start multiple performance counters and combine everything
> +	   afterwards, but that makes it complicated, and users can always
> +	   use PERF_TYPE_RAW.
> +
> +	   Note that I$ cache misses aren't counted by either of the two! */

Haven't really looked at the patch in detail, just noticed the following 
nit, please use the customary (multi-line) comment style:

  /*
   * Comment .....
   * ...... goes here.
   */

specified in Documentation/CodingStyle.

Thanks,

        Ingo

      reply	other threads:[~2013-08-29  6:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28 20:13 [PATCH] ARC: Add perf support Mischa Jonker
2013-08-29  6:41 ` Ingo Molnar [this message]

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=20130829064124.GB27322@gmail.com \
    --to=mingo@kernel.org \
    --cc=Mischa.Jonker@synopsys.com \
    --cc=Vineet.Gupta1@synopsys.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.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