From: "Wangnan (F)" <wangnan0@huawei.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <mingo@redhat.com>, <linux-kernel@vger.kernel.org>,
He Kuang <hekuang@huawei.com>,
Alexei Starovoitov <ast@kernel.org>,
"Arnaldo Carvalho de Melo" <acme@redhat.com>,
Brendan Gregg <brendan.d.gregg@gmail.com>,
"Jiri Olsa" <jolsa@kernel.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Namhyung Kim <namhyung@kernel.org>, Zefan Li <lizefan@huawei.com>,
<pi3orama@163.com>
Subject: Re: [PATCH 3/5] perf core: Prepare writing into ring buffer from end
Date: Fri, 25 Mar 2016 22:14:36 +0800 [thread overview]
Message-ID: <56F547CC.5000408@huawei.com> (raw)
In-Reply-To: <56F530C1.9010106@huawei.com>
On 2016/3/25 20:36, Wangnan (F) wrote:
>
>
> On 2016/3/25 20:26, Wangnan (F) wrote:
>>
>>
>> On 2016/3/23 17:50, Peter Zijlstra wrote:
>>> On Mon, Mar 14, 2016 at 09:59:43AM +0000, Wang Nan wrote:
>>>> Convert perf_output_begin to __perf_output_begin and make the later
>>>> function able to write records from the end of the ring buffer.
>>>> Following commits will utilize the 'backward' flag.
>>>>
>>>> This patch doesn't introduce any extra performance overhead since we
>>>> use always_inline.
>>> So while I agree that with __always_inline and constant propagation we
>>> _should_ end up with the same code, we have:
>>>
>>> $ size defconfig-build/kernel/events/ring_buffer.o.{pre,post}
>>> text data bss dec hex filename
>>> 3785 2 0 3787 ecb
>>> defconfig-build/kernel/events/ring_buffer.o.pre
>>> 3673 2 0 3675 e5b
>>> defconfig-build/kernel/events/ring_buffer.o.post
>>>
>>> The patch actually makes the file shrink.
>>>
>>> So I think we still want to have some actual performance numbers.
>>
>> In my environment the two objects are nearly idential:
>>
>>
>> $ objdump -d kernel/events/ring_buffer.o.new > ./out.new.S
>> $ objdump -d kernel/events/ring_buffer.o.old > ./out.old.S
>>
>> --- ./out.old.S 2016-03-25 12:18:52.060656423 +0000
>> +++ ./out.new.S 2016-03-25 12:18:45.376630269 +0000
>> @@ -1,5 +1,5 @@
>>
>> -kernel/events/ring_buffer.o.old: file format elf64-x86-64
>> +kernel/events/ring_buffer.o.new: file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>> @@ -320,7 +320,7 @@
>> 402: 4d 8d 04 0f lea (%r15,%rcx,1),%r8
>> 406: 48 89 c8 mov %rcx,%rax
>> 409: 4c 0f b1 43 40 cmpxchg %r8,0x40(%rbx)
>> - 40e: 48 39 c8 cmp %rcx,%rax
>> + 40e: 48 39 c1 cmp %rax,%rcx
>> 411: 75 b4 jne 3c7 <perf_output_begin+0xc7>
>> 413: 48 8b 73 58 mov 0x58(%rbx),%rsi
>> 417: 48 8b 43 68 mov 0x68(%rbx),%rax
>> @@ -357,7 +357,7 @@
>> 480: 85 c0 test %eax,%eax
>> 482: 0f 85 02 ff ff ff jne 38a <perf_output_begin+0x8a>
>> 488: 48 c7 c2 00 00 00 00 mov $0x0,%rdx
>> - 48f: be 7c 00 00 00 mov $0x7c,%esi
>> + 48f: be 89 00 00 00 mov $0x89,%esi
>> 494: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
>> 49b: c6 05 00 00 00 00 01 movb $0x1,0x0(%rip) # 4a2
>> <perf_output_begin+0x1a2>
>> 4a2: e8 00 00 00 00 callq 4a7 <perf_output_begin+0x1a7>
>> @@ -874,7 +874,7 @@
>> c39: eb e7 jmp c22
>> <perf_aux_output_begin+0x172>
>> c3b: 80 3d 00 00 00 00 00 cmpb $0x0,0x0(%rip) # c42
>> <perf_aux_output_begin+0x192>
>> c42: 75 93 jne bd7
>> <perf_aux_output_begin+0x127>
>> - c44: be 2b 01 00 00 mov $0x12b,%esi
>> + c44: be 49 01 00 00 mov $0x149,%esi
>> c49: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
>> c50: e8 00 00 00 00 callq c55
>> <perf_aux_output_begin+0x1a5>
>> c55: c6 05 00 00 00 00 01 movb $0x1,0x0(%rip) # c5c
>> <perf_aux_output_begin+0x1ac>
>>
>>
>> I think you enabled some unusual config options?
>>
>
> You must enabled CONFIG_OPTIMIZE_INLINING. Now I get similar result:
>
> $ size kernel/events/ring_buffer.o*
> text data bss dec hex filename
> 4545 4 8 4557 11cd
> kernel/events/ring_buffer.o.new
> 4641 4 8 4653 122d
> kernel/events/ring_buffer.o.old
>
> Thank you.
>
After enabling CONFIG_OPTIMIZE_INLINING:
Test its performance by calling 'close(-1)' for 3000000 times and
use 'perf record -o /dev/null -e raw_syscalls:* test-ring-buffer' to
capture system calls:
MEAN STDVAR
BASE 800077.1 23448.13
RAWPERF.PRE 2465858.0 603473.70
RAWPERF.POST 2471925.0 609437.60
Considering the high stdvar, after applying this patch the performance
is not change.
I'll put this number in my commit message.
Thank you.
next prev parent reply other threads:[~2016-03-25 14:15 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 9:59 [PATCH 0/5] perf core: Support overwrite ring buffer Wang Nan
2016-03-14 9:59 ` [PATCH 1/5] perf core: Introduce new ioctl options to pause and resume " Wang Nan
2016-03-23 9:16 ` Peter Zijlstra
2016-03-23 9:33 ` Wangnan (F)
2016-03-23 9:52 ` Peter Zijlstra
2016-03-23 12:43 ` Vince Weaver
2016-10-21 7:06 ` Michael Kerrisk (man-pages)
2016-10-21 7:13 ` Wangnan (F)
2016-10-21 8:55 ` Michael Kerrisk (man-pages)
2016-03-14 9:59 ` [PATCH 2/5] perf core: Set event's default overflow_handler Wang Nan
2016-03-23 17:50 ` Peter Zijlstra
2016-03-23 18:13 ` Will Deacon
2016-03-23 19:13 ` Peter Zijlstra
2016-03-23 19:29 ` Peter Zijlstra
2016-03-24 9:58 ` Will Deacon
2016-03-24 10:42 ` Peter Zijlstra
2016-03-14 9:59 ` [PATCH 3/5] perf core: Prepare writing into ring buffer from end Wang Nan
2016-03-23 9:50 ` Peter Zijlstra
2016-03-23 10:08 ` Wangnan (F)
2016-03-23 19:25 ` Alexei Starovoitov
2016-03-24 3:48 ` Wangnan (F)
2016-03-24 17:29 ` Alexei Starovoitov
2016-03-25 12:26 ` Wangnan (F)
2016-03-25 12:36 ` Wangnan (F)
2016-03-25 14:14 ` Wangnan (F) [this message]
2016-03-27 15:20 ` Peter Zijlstra
2016-03-27 15:30 ` pi3orama
2016-03-28 1:07 ` Wangnan (F)
2016-03-28 1:58 ` Wangnan (F)
2016-03-28 2:58 ` Wangnan (F)
2016-03-14 9:59 ` [PATCH 4/5] perf core: Add backward attribute to perf event Wang Nan
2016-03-14 9:59 ` [PATCH 5/5] perf core: Reduce perf event output overhead by new overflow handler Wang Nan
2016-03-23 10:02 ` Peter Zijlstra
-- strict thread matches above, loose matches on Subject: below --
2016-01-25 8:33 [PATCH 0/5] perf core: Read from overwrite ring buffer Wang Nan
2016-01-25 8:33 ` [PATCH 3/5] perf core: Prepare writing into ring buffer from end Wang Nan
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=56F547CC.5000408@huawei.com \
--to=wangnan0@huawei.com \
--cc=acme@redhat.com \
--cc=ast@kernel.org \
--cc=brendan.d.gregg@gmail.com \
--cc=hekuang@huawei.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=pi3orama@163.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;
as well as URLs for NNTP newsgroup(s).