From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
linux-kernel@vger.kernel.org, vince@deater.net,
eranian@google.com, Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH 0/4] perf, pt, coresight: AUX flags and VMX update
Date: Mon, 20 Feb 2017 13:09:46 -0300 [thread overview]
Message-ID: <20170220160946.GL4109@kernel.org> (raw)
In-Reply-To: <d791209c-c2b8-301c-a14e-3054ce4a11c7@intel.com>
Em Mon, Feb 20, 2017 at 05:39:43PM +0200, Adrian Hunter escreveu:
> On 20/02/17 17:18, Alexander Shishkin wrote:
> > Alexander Shishkin <alexander.shishkin@linux.intel.com> writes:
> >
> >> With the vmm_exclusive=0, PT seems to be much more usable on BDW now. This
> >> patchset does three things:
> >> * adds a flag to PERF_RECORD_AUX, signalling that a transaction has gaps
> >> in it (due to VMX root mode kicking in),
> >
> > In the above context, will something like this be fine?
> Looks fine to me.
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>
> > From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> > Subject: [PATCH] perf tools: Handle partial AUX records and print a warning
> > This patch decodes the 'partial' flag in AUX records and prints
> > a warning to the user, so that they don't have to guess why their
> > PT traces contain gaps (or missing altogether):
> >> Warning:
> >> AUX data had gaps in it 6 times out of 8!
The above should be left for a more verbose mode?
> >> Are you running a KVM guest in the background?
The warning should be a bit more precise, as you said, tuning
vmm_exclusive is key here, i.e.:
"Are you running a KVM guest in the background with
kvm_intel.vmm_exclusive=1?"
And that we can even figure out, its just a matter of reading:
[root@jouet ~]# cat /sys/module/kvm_intel/parameters/vmm_exclusive
Y
I have tested after setting that using:
modprobe kvm_intel vmm_exclusive=n
And I was able to get Intel PT records from a workload.
So perhaps we can get this patch in, which improves the situation, and
then, on top of it do these extra checks and give proper hints, ok?
- Arnaldo
> > Currently this is the only reason for partial records.
> >
> > Cc: Adrian Hunter <adrian.hunter@intel.com>
> > Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> > ---
> > tools/include/uapi/linux/perf_event.h | 1 +
> > tools/perf/util/event.c | 5 +++--
> > tools/perf/util/event.h | 1 +
> > tools/perf/util/session.c | 17 ++++++++++++++---
> > 4 files changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
> > index c66a485a24..8306415207 100644
> > --- a/tools/include/uapi/linux/perf_event.h
> > +++ b/tools/include/uapi/linux/perf_event.h
> > @@ -885,6 +885,7 @@ enum perf_callchain_context {
> > */
> > #define PERF_AUX_FLAG_TRUNCATED 0x01 /* record was truncated to fit */
> > #define PERF_AUX_FLAG_OVERWRITE 0x02 /* snapshot from overwrite mode */
> > +#define PERF_AUX_FLAG_PARTIAL 0x04 /* record contains gaps */
> >
> > #define PERF_FLAG_FD_NO_GROUP (1UL << 0)
> > #define PERF_FLAG_FD_OUTPUT (1UL << 1)
> > diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> > index 4ea7ce72ed..ba193cd019 100644
> > --- a/tools/perf/util/event.c
> > +++ b/tools/perf/util/event.c
> > @@ -1153,11 +1153,12 @@ int perf_event__process_exit(struct perf_tool *tool __maybe_unused,
> >
> > size_t perf_event__fprintf_aux(union perf_event *event, FILE *fp)
> > {
> > - return fprintf(fp, " offset: %#"PRIx64" size: %#"PRIx64" flags: %#"PRIx64" [%s%s]\n",
> > + return fprintf(fp, " offset: %#"PRIx64" size: %#"PRIx64" flags: %#"PRIx64" [%s%s%s]\n",
> > event->aux.aux_offset, event->aux.aux_size,
> > event->aux.flags,
> > event->aux.flags & PERF_AUX_FLAG_TRUNCATED ? "T" : "",
> > - event->aux.flags & PERF_AUX_FLAG_OVERWRITE ? "O" : "");
> > + event->aux.flags & PERF_AUX_FLAG_OVERWRITE ? "O" : "",
> > + event->aux.flags & PERF_AUX_FLAG_PARTIAL ? "P" : "");
> > }
> >
> > size_t perf_event__fprintf_itrace_start(union perf_event *event, FILE *fp)
> > diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
> > index c735c53a26..d7e53fe176 100644
> > --- a/tools/perf/util/event.h
> > +++ b/tools/perf/util/event.h
> > @@ -269,6 +269,7 @@ struct events_stats {
> > u64 total_lost;
> > u64 total_lost_samples;
> > u64 total_aux_lost;
> > + u64 total_aux_partial;
> > u64 total_invalid_chains;
> > u32 nr_events[PERF_RECORD_HEADER_MAX];
> > u32 nr_non_filtered_samples;
> > diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> > index 4cdbc8f5f1..abdb797fa4 100644
> > --- a/tools/perf/util/session.c
> > +++ b/tools/perf/util/session.c
> > @@ -1258,9 +1258,12 @@ static int machines__deliver_event(struct machines *machines,
> > case PERF_RECORD_UNTHROTTLE:
> > return tool->unthrottle(tool, event, sample, machine);
> > case PERF_RECORD_AUX:
> > - if (tool->aux == perf_event__process_aux &&
> > - (event->aux.flags & PERF_AUX_FLAG_TRUNCATED))
> > - evlist->stats.total_aux_lost += 1;
> > + if (tool->aux == perf_event__process_aux) {
> > + if (event->aux.flags & PERF_AUX_FLAG_TRUNCATED)
> > + evlist->stats.total_aux_lost += 1;
> > + if (event->aux.flags & PERF_AUX_FLAG_PARTIAL)
> > + evlist->stats.total_aux_partial += 1;
> > + }
> > return tool->aux(tool, event, sample, machine);
> > case PERF_RECORD_ITRACE_START:
> > return tool->itrace_start(tool, event, sample, machine);
> > @@ -1548,6 +1551,14 @@ static void perf_session__warn_about_errors(const struct perf_session *session)
> > stats->nr_events[PERF_RECORD_AUX]);
> > }
> >
> > + if (session->tool->aux == perf_event__process_aux &&
> > + stats->total_aux_partial != 0) {
> > + ui__warning("AUX data had gaps in it %" PRIu64 " times out of %u!\n\n"
> > + "Are you running a KVM guest in the background?\n\n",
> > + stats->total_aux_partial,
> > + stats->nr_events[PERF_RECORD_AUX]);
> > + }
> > +
> > if (stats->nr_unknown_events != 0) {
> > ui__warning("Found %u unknown events!\n\n"
> > "Is this an older tool processing a perf.data "
> >
next prev parent reply other threads:[~2017-02-20 16:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 13:33 [PATCH 0/4] perf, pt, coresight: AUX flags and VMX update Alexander Shishkin
2017-02-20 13:33 ` [PATCH 1/4] perf: Export AUX buffer helpers to modules Alexander Shishkin
2017-02-20 13:33 ` [PATCH 2/4] perf: Keep AUX flags in the output handle Alexander Shishkin
2017-02-20 17:01 ` kbuild test robot
2017-02-20 17:17 ` Alexander Shishkin
2017-02-20 20:42 ` Mathieu Poirier
2017-02-21 10:42 ` Will Deacon
2017-02-21 10:54 ` Alexander Shishkin
2017-03-16 11:22 ` [tip:perf/core] perf/core: " tip-bot for Will Deacon
2017-02-20 13:33 ` [PATCH 3/4] perf: Add a flag for partial AUX records Alexander Shishkin
2017-03-16 11:23 ` [tip:perf/core] perf/core: " tip-bot for Alexander Shishkin
2017-03-16 14:24 ` Vince Weaver
2017-02-20 13:33 ` [PATCH 4/4] perf/x86/intel/pt: Handle VMX better Alexander Shishkin
2017-03-16 11:24 ` [tip:perf/core] " tip-bot for Alexander Shishkin
2017-02-20 15:18 ` [PATCH 0/4] perf, pt, coresight: AUX flags and VMX update Alexander Shishkin
2017-02-20 15:39 ` Adrian Hunter
2017-02-20 16:09 ` Arnaldo Carvalho de Melo [this message]
2017-02-20 16:31 ` Alexander Shishkin
2017-03-16 16:41 ` Alexander Shishkin
2017-03-21 6:50 ` [tip:perf/core] tools lib api fs: Introduce sysfs__read_bool tip-bot for Alexander Shishkin
2017-03-21 6:51 ` [tip:perf/core] tools include: Sync {,tools/}include/uapi/linux/perf_event.h tip-bot for Alexander Shishkin
2017-03-21 6:51 ` [tip:perf/core] perf tools: Handle partial AUX records and print a warning tip-bot for Alexander Shishkin
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=20170220160946.GL4109@kernel.org \
--to=acme@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=vince@deater.net \
/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.