From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: Robert Richter <robert.richter@amd.com>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Paul Mackerras <paulus@samba.org>,
David Miller <davem@davemloft.net>,
Will Deacon <will.deacon@arm.com>,
Paul Mundt <lethal@linux-sh.org>
Subject: Re: [PATCH 1/7] perf: introduce raw_type attribute to specify the type of a raw sample
Date: Thu, 20 May 2010 12:37:39 +0200 [thread overview]
Message-ID: <1274351859.5605.13961.camel@twins> (raw)
In-Reply-To: <AANLkTikWSOPpHsvJGht7c7QnwcOk-nMyBNhY-g6QpNzg@mail.gmail.com>
On Thu, 2010-05-20 at 11:42 +0200, Stephane Eranian wrote:
> > For Instruction-Fetch:
> > 32:47 latency (r/w)
> Your are mixing output and input parameters.
>
> The only input parameters you have are:
> - sample-period, enable, random
> The rest is output only.
Ah, my bad, I thought it was a r/w field.
> > encode these IBS things as:
> >
> > 0x87 Instruction Fetch Stall -- Ins-Fetch
> > 0xC0 Retired Instructions -- Ins-Exec
> >
> I think those events do not map to the behavior of IBS. We have
> add that discussion before.
Hrm,. so there are no regular events that count the same thing as the
IBS things? That really sucks.
So yeah, you might as well expose it as a whole separate PMU using Lin's
stuff.
> > The Ins-Exec will have to re-construct the actual event->count by adding
> > sample-period on each interrupt, as it seems we lack an actual counter
> > in hardware.
> >
> For what? counting mode?
Yeah, events are supposed to count.
> > Furthermore, these counters will have to deal with sample-period > 2^16
> > by 'ignoring' interrupts until we get ->period_left down to 0.
> >
> Well, it's not 2^16, it's 2^20 but bottom 4 bits must be zero.
> What about simply failing perf_event_open() is sample_period does not fit the
> constraint?
Why, its simple enough to ignore a few interrupts, we do the same for
all other implementations.
> > The extra data could possibly be exposed through attaching non-sampling
> > group events and using SAMPLE_READ, like L1-misses, although
> > reconstructing the count from just one bit seems 'interesting'.
> >
> > The IbsFetchLinAd/IbsOpRip would go straight into PERF_SAMPLE_IP by
> > replacing pt_regs->ip I guess.
> >
> > IbsDcLinAd goes into PERF_SAMPLE_ADDR
> >
> What about the rest, the TLB, alignment, data sources?
Dunno, reconstruct sensible counters? Surely the software that uses IBS
does something useful with that data? What does libpfm do with the IBS
data?
next prev parent reply other threads:[~2010-05-20 10:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 21:20 [PATCH 0/7] perf: implement AMD IBS (v2) Robert Richter
2010-05-19 21:20 ` [PATCH 1/7] perf: introduce raw_type attribute to specify the type of a raw sample Robert Richter
2010-05-19 22:02 ` Corey Ashford
2010-05-20 6:51 ` Ingo Molnar
2010-05-20 23:06 ` Robert Richter
2010-05-20 22:46 ` Robert Richter
2010-05-20 8:10 ` Stephane Eranian
2010-05-20 9:23 ` Peter Zijlstra
2010-05-20 9:42 ` Stephane Eranian
2010-05-20 10:37 ` Peter Zijlstra [this message]
2010-05-20 12:13 ` Stephane Eranian
2010-05-20 15:22 ` Robert Richter
2012-11-23 12:00 ` Robert Richter
2010-05-20 14:08 ` Robert Richter
2010-05-20 16:55 ` Ingo Molnar
2010-05-20 17:07 ` Robert Richter
2010-05-20 17:16 ` Peter Zijlstra
2010-05-20 13:58 ` Robert Richter
2010-05-20 14:14 ` Stephane Eranian
2010-05-20 14:30 ` Stephane Eranian
2010-05-20 15:48 ` Robert Richter
2010-05-19 21:20 ` [PATCH 2/7] perf, x86: introduce bit range for special pmu events Robert Richter
2010-05-19 21:20 ` [PATCH 3/7] perf, x86: modify some code to allow the introduction of ibs events Robert Richter
2010-05-19 21:20 ` [PATCH 4/7] perf, x86: implement IBS feature detection Robert Richter
2010-05-19 21:20 ` [PATCH 5/7] perf, x86: setup NMI handler for IBS Robert Richter
2010-05-19 21:20 ` [PATCH 6/7] perf, x86: implement AMD IBS event configuration Robert Richter
2010-05-19 21:20 ` [PATCH 7/7] perf, x86: implement the ibs interrupt handler Robert Richter
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=1274351859.5605.13961.camel@twins \
--to=peterz@infradead.org \
--cc=davem@davemloft.net \
--cc=eranian@google.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=robert.richter@amd.com \
--cc=will.deacon@arm.com \
/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
all inboxes | Powered by JetHome®