All of lore.kernel.org
 help / color / mirror / Atom feed
From: pi3orama <pi3orama@163.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Wangnan (F)" <wangnan0@huawei.com>,
	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>
Subject: Re: [PATCH 3/5] perf core: Prepare writing into ring buffer from end
Date: Sun, 27 Mar 2016 23:30:19 +0800	[thread overview]
Message-ID: <73914DEA-D304-4997-9CEA-9689E3BAA7BE@163.com> (raw)
In-Reply-To: <20160327152005.GU6356@twins.programming.kicks-ass.net>



发自我的 iPhone

> 在 2016年3月27日，下午11:20，Peter Zijlstra <peterz@infradead.org> 写道：
> 
> On Fri, Mar 25, 2016 at 10:14:36PM +0800, Wangnan (F) wrote:
>>>> I think you enabled some unusual config options?
> 
> x86_64-defconfig
> 
>>> You must enabled CONFIG_OPTIMIZE_INLINING. Now I get similar result:
> 
> It has that indeed.
> 
>> 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.
> 
> Why is your variance so immense? And doesn't that render the
> measurements pointless?
> 

For some unknown reason, about
10% of these results raises 2 times of normal
results. Say, "normal results" are about
2200000, but those "outliers" are about
4400000 (I can't access raw data now).
Variance becomes much smaller if I remove
those outliers.

I guess the outliers is caused by some type
of lock stepping? No clue about it.

Thank you.

  reply	other threads:[~2016-03-27 15:31 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)
2016-03-27 15:20           ` Peter Zijlstra
2016-03-27 15:30             ` pi3orama [this message]
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=73914DEA-D304-4997-9CEA-9689E3BAA7BE@163.com \
    --to=pi3orama@163.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=wangnan0@huawei.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 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.