From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Eric B Munson <emunson@mgebm.net>
Cc: a.p.zijlstra@chello.nl, linux-kernel@vger.kernel.org,
paulus@samba.org, anton@samba.org, acme@ghostprotocols.net,
mingo@elte.hu, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
Date: Thu, 31 Mar 2011 17:04:36 +1100 [thread overview]
Message-ID: <1301551476.2407.61.camel@pasglop> (raw)
In-Reply-To: <20110330183656.GA2564@mgebm.net>
On Wed, 2011-03-30 at 14:36 -0400, Eric B Munson wrote:
> On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote:
>
> > On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote:
> > > Here I made the assumption that the hardware would never remove more events in
> > > a speculative roll back than it had added. This is not a situation I
> > > encoutered in my limited testing, so I didn't think underflow was possible. I
> > > will send out a V2 using the signed 32 bit delta and remeber to CC stable
> > > this time.
> >
> > I'm not thinking about underflow but rollover... or that isn't possible
> > with those counters ? IE. They don't wrap back to 0 after hitting
> > ffffffff ?
> >
>
> They do roll over to 0 after ffffffff, but I thought that case was already
> covered by the perf_event_interrupt. Are you concerned that we will reset a
> counter and speculative roll back will underflow that counter?
No, but take this part of the patch:
> --- a/arch/powerpc/kernel/perf_event.c
> +++ b/arch/powerpc/kernel/perf_event.c
> @@ -416,6 +416,15 @@ static void power_pmu_read(struct perf_event *event)
> prev = local64_read(&event->hw.prev_count);
> barrier();
> val = read_pmc(event->hw.idx);
> + /*
> + * POWER7 can roll back counter values, if the new value is
> + * smaller than the previous value it will cause the delta
> + * and the counter to have bogus values. If this is the
> + * case skip updating anything until the counter grows again.
> + * This can lead to a small lack of precision in the counters.
> + */
> + if (val < prev)
> + return;
> } while (local64_cmpxchg(&event->hw.prev_count, prev, val) != prev);
Doesn't that mean that power_pmu_read() can only ever increase the value of
the perf_event and so will essentially -stop- once the counter rolls over ?
Similar comments every where you do this type of comparison.
Cheers,
Ben.
next prev parent reply other threads:[~2011-03-31 6:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-25 13:28 [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks Eric B Munson
2011-03-29 6:03 ` Benjamin Herrenschmidt
2011-03-29 14:25 ` Eric B Munson
2011-03-29 21:12 ` Benjamin Herrenschmidt
2011-03-30 18:36 ` Eric B Munson
2011-03-31 6:04 ` Benjamin Herrenschmidt [this message]
2011-03-31 16:14 ` Eric B Munson
2011-04-06 21:27 ` Eric B Munson
2011-04-07 4:22 ` Benjamin Herrenschmidt
2011-04-07 16:16 ` Eric B Munson
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=1301551476.2407.61.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=anton@samba.org \
--cc=emunson@mgebm.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@elte.hu \
--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;
as well as URLs for NNTP newsgroup(s).