From: Ingo Molnar <mingo@kernel.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: peterz@infradead.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 3/3] perf, x86: Add INST_RETIRED.ALL workarounds
Date: Mon, 23 Mar 2015 10:38:54 +0100 [thread overview]
Message-ID: <20150323093854.GA24993@gmail.com> (raw)
In-Reply-To: <1424225886-18652-3-git-send-email-andi@firstfloor.org>
* Andi Kleen <andi@firstfloor.org> wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> On Broadwell INST_RETIRED.ALL cannot be used with any period
> that doesn't have the lowest 6 bits cleared. And the period
> should not be smaller than 128.
Sloppy changelog: a most basic question is not answered by the
changelog: what happens in practice when the period is set to a
smaller value than 128?
> +/*
> + * Broadwell:
> + * The INST_RETIRED.ALL period always needs to have lowest
> + * 6bits cleared (BDM57). It shall not use a period smaller
> + * than 100 (BDM11). We combine the two to enforce
> + * a min-period of 128.
> + */
Sloppy comment: that's not what we do:
> +static unsigned bdw_limit_period(struct perf_event *event, unsigned left)
> +{
> + if ((event->hw.config & INTEL_ARCH_EVENT_MASK) ==
> + X86_CONFIG(.event=0xc0, .umask=0x01)) {
> + if (left < 128)
> + left = 128;
> + left &= ~0x3fu;
> + }
> + return left;
We enforce a minimum period of 128 and round the requested period to
64.
I think in this case it would be useful to tooling if we updated the
syscall attribute with the real period value that was used, to not
skew tooling output.
Thanks,
Ingo
next prev parent reply other threads:[~2015-03-23 9:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-18 2:18 [PATCH 1/3] perf, x86: Add new cache events table for Haswell Andi Kleen
2015-02-18 2:18 ` [PATCH 2/3] perf, x86: Add Broadwell core support Andi Kleen
2015-03-27 11:39 ` [tip:perf/core] perf/x86/intel: " tip-bot for Andi Kleen
2015-02-18 2:18 ` [PATCH 3/3] perf, x86: Add INST_RETIRED.ALL workarounds Andi Kleen
2015-03-23 9:38 ` Ingo Molnar [this message]
2015-03-23 10:19 ` Peter Zijlstra
2015-03-23 10:39 ` Ingo Molnar
2015-03-23 12:35 ` Peter Zijlstra
2015-03-23 13:32 ` Ingo Molnar
2015-03-27 11:39 ` [tip:perf/core] perf/x86/intel: " tip-bot for Andi Kleen
2015-03-23 9:45 ` [PATCH 1/3] perf, x86: Add new cache events table for Haswell Ingo Molnar
2015-03-23 13:53 ` Peter Zijlstra
2015-03-23 13:55 ` Ingo Molnar
2015-03-27 11:39 ` [tip:perf/core] perf/x86/intel: " tip-bot for Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2015-02-11 0:40 [PATCH 1/3] perf, x86: " Andi Kleen
2015-02-11 0:40 ` [PATCH 3/3] perf, x86: Add INST_RETIRED.ALL workarounds Andi Kleen
2015-02-09 19:17 [PATCH 1/3] perf, x86: Add new cache events table for Haswell Andi Kleen
2015-02-09 19:17 ` [PATCH 3/3] perf, x86: Add INST_RETIRED.ALL workarounds Andi Kleen
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=20150323093854.GA24993@gmail.com \
--to=mingo@kernel.org \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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