From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752547AbcAVEqz (ORCPT ); Thu, 21 Jan 2016 23:46:55 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:26157 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751476AbcAVEqu (ORCPT ); Thu, 21 Jan 2016 23:46:50 -0500 Message-ID: <56A1B3D9.20506@huawei.com> Date: Fri, 22 Jan 2016 12:45:13 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexei Starovoitov CC: , , , He Kuang , Arnaldo Carvalho de Melo , Brendan Gregg , Jiri Olsa , Masami Hiramatsu , Namhyung Kim , Zefan Li , Subject: Re: [PATCH 0/6] perf core: Read from overwrite ring buffer 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> <20160122032128.GB6593@ast-mbp.thefacebook.com> In-Reply-To: <20160122032128.GB6593@ast-mbp.thefacebook.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56A1B3EB.00BB,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5057bfd7eb6a7d52bb13d4de24c71eb6 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/1/22 11:21, Alexei Starovoitov wrote: > 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? Yes. But notice STDVAR, we can't say 'WRTBKWRD' outperform 'RAWOVWRT'. However, at least 'WRTBKWRD' should be as fast as 'RAWOVWRT'. > nice. I guess it makes snese that overwrite is faster. In no-overwrite case perf itself wakes up many times to collect data, I guess it is the source of high stdvar. > I guess than moving the header to the end will have the same > performance in this benchmark, since RAWOVWRT is the same as well. > Yes. Do you want to test it by yourself? The code is ready. Thank you.