From: Namhyung Kim <namhyung@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: David Ahern <dsahern@gmail.com>,
acme@ghostprotocols.net, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Mike Galbraith <efault@gmx.de>,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH] perf record: mmap output file - RFC
Date: Fri, 27 Sep 2013 11:24:53 +0900 [thread overview]
Message-ID: <87a9izovbe.fsf@sejong.aot.lge.com> (raw)
In-Reply-To: <20130926175105.GB9121@krava.brq.redhat.com> (Jiri Olsa's message of "Thu, 26 Sep 2013 19:51:05 +0200")
Hi Jiri and David,
On Thu, 26 Sep 2013 19:51:05 +0200, Jiri Olsa wrote:
> On Sun, Sep 22, 2013 at 08:05:59PM -0600, David Ahern wrote:
>> When recording raw_syscalls for the entire system, e.g.,
>> perf record -e raw_syscalls:*,sched:sched_switch -a -- sleep 1
>>
>> you end up with a negative feedback loop as perf itself calls
>> write() fairly often. This patch mmap's the file in chunks of 64M
>> at a time and copies events from the event buffers to the file
>> avoiding write system calls.
>
> moved processing into userspace:
>
> 17.24% -17.10% libpthread-2.15.so [.] __write_nocancel
> ...
> 0.07% +0.64% libc-2.15.so [.] __memcpy_sse2
> 0.02% +51.84% libc-2.15.so [.] __memcpy_ssse3_back
> 0.01% +0.34% libc-2.15.so [.] __mempcpy_sse2
> ...
>>
>> Before (with write syscall):
>>
>> perf record -o /tmp/perf.data -e raw_syscalls:*,sched:sched_switch -a -- sleep 1
>> [ perf record: Woken up 0 times to write data ]
>> [ perf record: Captured and wrote 81.843 MB /tmp/perf.data (~3575786 samples) ]
>>
>> After (using mmap):
>>
>> perf record -o /tmp/perf.data -e raw_syscalls:*,sched:sched_switch -a -- sleep 1
>> [ perf record: Woken up 31 times to write data ]
>
> ^^^^^^^^
> but it's still faster, since we finally get perf a chance to sleep ;-)
>
> new time:
> real 0m30.392s
> user 0m0.041s
> sys 0m0.389s
>
> old time:
> real 0m32.235s
> user 0m3.080s
> sys 0m14.444s
But why the new user time took so short? I guess it should take at
least 10 seconds or so. Any ideas?
>
>
>> [ perf record: Captured and wrote 8.203 MB /tmp/perf.data (~358388 samples) ]
>>
>> Before I get too far down this path I wanted to get comments on the approach.
>
> I think it's worthwhile doing this
Indeed! It looks like a nice improvement.
Thanks,
Namhyung
next prev parent reply other threads:[~2013-09-27 2:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-23 2:05 [PATCH] perf record: mmap output file - RFC David Ahern
2013-09-26 17:51 ` Jiri Olsa
2013-09-26 18:12 ` David Ahern
2013-09-26 18:23 ` Jiri Olsa
2013-09-26 23:17 ` David Ahern
2013-09-27 6:29 ` Ingo Molnar
2013-09-27 2:24 ` Namhyung Kim [this message]
2013-10-09 13:33 ` Jiri Olsa
2013-10-09 13:46 ` David Ahern
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=87a9izovbe.fsf@sejong.aot.lge.com \
--to=namhyung@kernel.org \
--cc=acme@ghostprotocols.net \
--cc=dsahern@gmail.com \
--cc=efault@gmx.de \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.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.