From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752092AbcAVDWA (ORCPT ); Thu, 21 Jan 2016 22:22:00 -0500 Received: from mail-pa0-f47.google.com ([209.85.220.47]:36621 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751874AbcAVDVa (ORCPT ); Thu, 21 Jan 2016 22:21:30 -0500 Date: Thu, 21 Jan 2016 19:21:29 -0800 From: Alexei Starovoitov To: "Wangnan (F)" Cc: peterz@infradead.org, ast@kernel.org, linux-kernel@vger.kernel.org, He Kuang , Arnaldo Carvalho de Melo , Brendan Gregg , Jiri Olsa , Masami Hiramatsu , Namhyung Kim , Zefan Li , pi3orama@163.com Subject: Re: [PATCH 0/6] perf core: Read from overwrite ring buffer Message-ID: <20160122032128.GB6593@ast-mbp.thefacebook.com> References: <20160118120230.GP6357@twins.programming.kicks-ass.net> <1453202210-134429-1-git-send-email-wangnan0@huawei.com> <20160119174239.GA83683@ast-mbp.thefacebook.com> <569EE4E6.7040804@huawei.com> <20160120022020.GA89318@ast-mbp.thefacebook.com> <56A07FF3.2090009@huawei.com> <56A1921F.5090808@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56A1921F.5090808@huawei.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 22, 2016 at 10:21:19AM +0800, Wangnan (F) wrote: > > > On 2016/1/21 14:51, Wangnan (F) wrote: > > > > > >On 2016/1/20 10:20, Alexei Starovoitov wrote: > >>On Wed, Jan 20, 2016 at 09:37:42AM +0800, Wangnan (F) wrote: > >>> > >>>On 2016/1/20 1:42, Alexei Starovoitov wrote: > >>>>On Tue, Jan 19, 2016 at 11:16:44AM +0000, Wang Nan wrote: > >>>>>This patchset introduces two methods to support reading from > >>>>>overwrite. > >>>>> > >>>>> 1) Tailsize: write the size of an event at the end of it > >>>>> 2) Backward writing: write the ring buffer from the end of it to > >>>>>the > >>>>> beginning. > >>>>what happend with your other idea of moving the whole header to the > >>>>end? > >>>>That felt better than either of these options. > >>>I'll try it today. However, putting all of the three together is > >>>not as easy as this patchset. > >>I'm missing something. Why all three in one set? > > > >Can't implement all three in one, but implement two of them make > >benchmarking simpler :) > > > >Here comes some numbers. > > > >I attach a target program at the end of this mail. It calls > >close(-1) for 3000000 times, and use gettimeofday to check > >how many us it takes. > > > >Following cases are tested: > > > > > > BASE : ./a.out > > RAWPERF : ./perf record -o /dev/null -e raw_syscalls:* ./a.out > > WRTBKWRD: ./perf record -o /dev/null -e raw_syscalls:* ./a.out > > TAILSIZE: ./perf record --no-has-write-backward -o /dev/null -e > >raw_syscalls:*/overwrite/ ./a.out > > RAWOVWRT: ./perf record --no-has-write-backward --no-has-tailsize -o > >/dev/null -e raw_syscalls:*/overwrite/ ./a.out > > > >With this script: > > > >func() { > > for x in `seq 1 100` ; do $1; done | tee data_$2 > >} > > > >func ./a.out base > >func "./perf record -o /dev/null -e raw_syscalls:* ./a.out" rawperf > >func "./perf record -o /dev/null -e raw_syscalls:*/overwrite/ ./a.out" > >wrtbkwrd > >func "./perf record -o /dev/null --no-has-write-backward -e > >raw_syscalls:*/overwrite/ ./a.out" tailsize > >func "./perf record -o /dev/null --no-has-write-backward --no-has-tailsize > >-o /dev/null -e raw_syscalls:*/overwrite/ ./a.out" rawovwrt > > > >Result: > > > > MEAN STDVAR > >BASE : 879870.81 11913.13 > >RAWPERF : 2603854.7 706658.4 > >WRTBKWRD: 2313301.220 6727.957 > >TAILSIZE: 2383051.860 5248.061 > >RAWOVWRT: 2315273.180 5221.025 > > Add a number: I tested original perf overwrite ring buffer in pure v4.4 > on the same machine: > > MEAN STDVAR > RAWOVWRT(original): 2323970.45 5103.39 > > So I think backward writing method doesn't add extra overhead into > fastpath. > > I will send this patchset again with several bugs fixed. After that > I'll start working on tail-header if it is still required. interesting. did I read the numbers correctly that 'write backwards' method is actually the fastest? even faster than no-overwrite? nice. I guess it makes snese that overwrite is faster. I guess than moving the header to the end will have the same performance in this benchmark, since RAWOVWRT is the same as well.