From: Jiri Olsa <jolsa@redhat.com>
To: Alexander Yarygin <yarygin@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
linux-kernel@vger.kernel.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@kernel.org>, Mike Galbraith <efault@gmx.de>,
Namhyung Kim <namhyung.kim@lge.com>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 1/2] perf session: Add option to copy events when queueing
Date: Mon, 22 Sep 2014 09:04:17 +0200 [thread overview]
Message-ID: <20140922070417.GB1191@krava.brq.redhat.com> (raw)
In-Reply-To: <87r3z86lnu.fsf@linux.vnet.ibm.com>
On Fri, Sep 19, 2014 at 12:48:21PM +0400, Alexander Yarygin wrote:
> David Ahern <dsahern@gmail.com> writes:
>
> > On 9/18/14, 2:21 PM, David Ahern wrote:
> >> On 9/18/14, 12:53 PM, Arnaldo Carvalho de Melo wrote:
> >>> If nobody objects I'll merge this patch, as it fixes problems, but I
> >>> wonder if the best wouldn't be simply not calling
> >>> perf_evlist__mmap_consume() till the last event there is in fact
> >>> consumed... I.e. as we _really_ consume the events, we remove it from
> >>> there.
> >>>
> >>> Instead of consuming the event at perf_tool->sample() time, we would
> >>> do it at perf_tool->finished_round(), would that be feasible? Has anyone
> >>> tried this?
> >>
> >> Hmmm... haven't tried this. Conceptually it should work - at least
> >> nothing comes to mind at the moment.
> >
> > Upon further review ...
> >
> > Alex you might want to try this first. Malloc and copy of all events
> > is going to bring some serious overhead. Can avoid that if consuming
> > the event in finished_round works.
> >
> > David
>
> I've tried that:
>
> --- a/tools/perf/builtin-kvm.c
> +++ b/tools/perf/builtin-kvm.c
> @@ -737,7 +737,6 @@ static s64 perf_kvm__mmap_read_idx(struct perf_kvm_stat *kvm, int idx,
> * FIXME: Here we can't consume the event, as perf_session_queue_event will
> * point to it, and it'll get possibly overwritten by the kernel.
> */
> - perf_evlist__mmap_consume(kvm->evlist, idx);
>
> if (err) {
> pr_err("Failed to enqueue sample: %d\n", err);
> @@ -787,6 +786,10 @@ static int perf_kvm__mmap_read(struct perf_kvm_stat *kvm)
> if (ntotal) {
> kvm->session->ordered_samples.next_flush = flush_time;
> err = kvm->tool.finished_round(&kvm->tool, NULL, kvm->session);
> +
> + for (i = 0; i < kvm->evlist->nr_mmaps; i++)
> + perf_evlist__mmap_consume(kvm->evlist, i);
> +
> if (err) {
> if (kvm->lost_events)
> pr_info("\nLost events: %" PRIu64
> "\n\n",
>
> It did't work. Turned out that there is at least one event alive after
> finished_round(), usually I get more - ~20. Not sure why, maybe it's
> another problem which should be solved at first?
The flush timestamp at the moment of the ROUND event is not
the max timestamp of the queue. It's set as max queue timestamp
by the previous flush as explained in util/session.c
process_finished_round function comment
>
>
> Also, I tried to follow 'perf-top' way:
>
> while (perf_evlist__mmap_read() != NULL) {
> perf_evlist__parse_sample();
> perf_event__process_sample();
> perf_evlist__mmap_consume();
> }
>
> I.e. without session_queue. In this case perf won't crash, but it will
> process significantly less events.
right, I guess they are dropped in kernel due to the
userspace processing being slow
I'm ok with this solution.. with some comments in my other email
jirka
next prev parent reply other threads:[~2014-09-22 7:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-18 17:07 [PATCH 0/2] perf kvm stat live: Copy events Alexander Yarygin
2014-09-18 17:07 ` [PATCH 1/2] perf session: Add option to copy events when queueing Alexander Yarygin
2014-09-18 18:53 ` Arnaldo Carvalho de Melo
2014-09-18 20:21 ` David Ahern
2014-09-18 20:29 ` David Ahern
2014-09-19 8:48 ` Alexander Yarygin
2014-09-19 14:21 ` David Ahern
2014-09-19 16:25 ` Alexander Yarygin
2014-09-22 7:04 ` Jiri Olsa [this message]
2014-09-22 7:04 ` Jiri Olsa
2014-09-29 18:33 ` Arnaldo Carvalho de Melo
2014-09-18 17:07 ` [PATCH 2/2] perf kvm stat live: Enable events copying Alexander Yarygin
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=20140922070417.GB1191@krava.brq.redhat.com \
--to=jolsa@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=borntraeger@de.ibm.com \
--cc=dsahern@gmail.com \
--cc=efault@gmx.de \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung.kim@lge.com \
--cc=paulus@samba.org \
--cc=yarygin@linux.vnet.ibm.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®