From: Alexander Yarygin <yarygin@linux.vnet.ibm.com>
To: David Ahern <dsahern@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Alexander Yarygin <yarygin@linux.vnet.ibm.com>
Subject: Re: [PATCH RFC] perf kvm stat live: cache mmap()ed events
Date: Mon, 15 Sep 2014 16:57:34 +0400 [thread overview]
Message-ID: <874mw9vy69.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <5415B6B9.2040607@gmail.com> (David Ahern's message of "Sun, 14 Sep 2014 09:39:37 -0600")
David Ahern <dsahern@gmail.com> writes:
> On 9/12/14, 10:27 AM, Alexander Yarygin wrote:
>> During mmap() process 'perf kvm stat live' gets a pointer to events and
>> passes them to the session queue. Events are stored in shared memory and
>> eventually they will be overwritten by the kernel. The problem is, that
>> when events come too fast, old events can be overwritten before they
>> have been processed that can lead to perf crash.
>>
>> To prevent that happening, we can copy upcoming events and pass a copy
>> to the session queue. There is a safe place to copy event: before
>> perf_evlist__mmap_consume() is executed. There are 3 places to free it:
>> when event is processed, when it's lost and on exit, if it's turned out
>> unprocessed.
>
> Did you see what I proposed a year ago:
> https://lkml.org/lkml/2013/9/6/388
>
> The intent is to keep the copy generic and not local a command since
> conceptually other live commands need the same.
>
> David
Hello,
Yes, your patch works fine. But as far as I understand, right now only
the 'perf kvm stat live' is infected: other 'live' tools were fixed by
the patch "PERF: The tail position of the event buffer should only be modified
after actually use that event." and since they don't use ordered queue
they don't need a copying. That's why I came up with 'perf kvm stat
live' specific approach. Maybe I missed something...
Anyhow, having >30K events is a quite usual situation on s390 and the
'perf kvm stat live' command hardly works there, so it would be good to
have at least some working solution. Any ideas? :)
Thanks.
next prev parent reply other threads:[~2014-09-15 12:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 16:27 [PATCH RFC] perf kvm stat live: cache mmap()ed events Alexander Yarygin
2014-09-14 13:24 ` Jiri Olsa
2014-09-14 15:39 ` David Ahern
2014-09-15 12:57 ` Alexander Yarygin [this message]
2014-09-15 14:23 ` David Ahern
2014-09-15 18:45 ` Arnaldo Carvalho de Melo
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=874mw9vy69.fsf@linux.vnet.ibm.com \
--to=yarygin@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=borntraeger@de.ibm.com \
--cc=dsahern@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--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 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.