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] [day] [month] [year] [list]
Message-ID: <20130829064124.GB27322@gmail.com>
Date:	Thu, 29 Aug 2013 08:41:24 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Mischa Jonker <Mischa.Jonker@...opsys.com>
Cc:	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARC: Add perf support


* Mischa Jonker <Mischa.Jonker@...opsys.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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ