From: Michael Ellerman <michael@ellerman.id.au>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org, mikey@neuling.org
Subject: Re: [PATCH] powerpc, perf: Configure BHRB filter before enabling PMU interrupts
Date: Wed, 9 Oct 2013 12:21:30 +1100 [thread overview]
Message-ID: <20131009012130.GA23780@concordia> (raw)
In-Reply-To: <5253B26E.3020800@linux.vnet.ibm.com>
On Tue, Oct 08, 2013 at 12:51:18PM +0530, Anshuman Khandual wrote:
> On 10/08/2013 09:51 AM, Michael Ellerman wrote:
> > On Mon, Oct 07, 2013 at 10:00:26AM +0530, Anshuman Khandual wrote:
> >> Right now the `config_bhrb` PMU specific call happens after write_mmcr0
> >> which actually enables the PMU for event counting and interrupt. So
> >> there is a small window of time where the PMU and BHRB runs without the
> >> required HW branch filter (if any) enabled in BHRB. This can cause some
> >> of the branch samples to be collected through BHRB without any filter
> >> being applied and hence affecting the correctness of the results. This
> >> patch moves the BHRB config function call before enabling the interrupts.
> >
> > Patch looks good.
> >
> > But it reminds me I have an item in my TODO list:
> > - "Why can't config_bhrb() be done in compute_mmcr()" ?
> >
>
> compute_mmcr() function deals with generic MMCR* configs for normal PMU
> events. Even if BHRB config touches MMCRA register, it's configuration
> does not interfere with the PMU config for general events. So its best
> to keep them separate.
I'm unconvinced. If they'd been together to begin with this bug never
would have happened.
And there's the added overhead of another indirect function call.
> Besides, we can always look at these code consolidation
> issues in future.
The future is now.
> But this patch solves a problem which is happening right now.
Sure, I'm not saying we shouldn't merge it as a fix. But I think we
should do the cleanup to move it into compute_mmcr() for 3.13.
cheers
next prev parent reply other threads:[~2013-10-09 1:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-07 4:30 [PATCH] powerpc, perf: Configure BHRB filter before enabling PMU interrupts Anshuman Khandual
2013-10-08 4:21 ` Michael Ellerman
2013-10-08 7:21 ` Anshuman Khandual
2013-10-09 1:21 ` Michael Ellerman [this message]
2013-10-09 4:46 ` Anshuman Khandual
2013-10-09 6:03 ` Michael Ellerman
2013-10-10 8:50 ` Anshuman Khandual
2013-10-11 2:11 ` Michael Ellerman
2013-10-11 4:32 ` Anshuman Khandual
2013-10-14 6:19 ` Michael Ellerman
2013-10-16 4:30 ` Anshuman Khandual
2013-12-13 6:46 ` Anshuman Khandual
-- strict thread matches above, loose matches on Subject: below --
2013-12-18 2:14 Michael Ellerman
2013-12-18 3:41 ` Anshuman Khandual
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=20131009012130.GA23780@concordia \
--to=michael@ellerman.id.au \
--cc=khandual@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikey@neuling.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.