From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757126AbcASCzm (ORCPT ); Mon, 18 Jan 2016 21:55:42 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:54462 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756914AbcASCzi (ORCPT ); Mon, 18 Jan 2016 21:55:38 -0500 Message-ID: <569DA586.6070302@huawei.com> Date: Tue, 19 Jan 2016 10:55:02 +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: Peter Zijlstra CC: , , , , He Kuang , Alexei Starovoitov , Arnaldo Carvalho de Melo , Brendan Gregg , "David S. Miller" , "Jiri Olsa" , Masami Hiramatsu , Namhyung Kim Subject: Re: [PATCH] perf core: Introduce new ioctl options to pause and resume ring buffer References: <20160112141430.GH6357@twins.programming.kicks-ass.net> <1453117921-122482-1-git-send-email-wangnan0@huawei.com> <20160118120230.GP6357@twins.programming.kicks-ass.net> In-Reply-To: <20160118120230.GP6357@twins.programming.kicks-ass.net> 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.0A020205.569DA5A6.0111,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2f9af567fcfbfd756a079899c638c87c Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/1/18 20:02, Peter Zijlstra wrote: > On Mon, Jan 18, 2016 at 11:52:01AM +0000, Wang Nan wrote: > >> +#define PERF_EVENT_IOC_PAUSE_OUTPUT _IO ('$', 9) >> +#define PERF_EVENT_IOC_RESUME_OUTPUT _IO ('$', 10) > Would not a single IOCTL with a 'boolean' parameter make more sense? Good suggestion. >> +++ b/kernel/events/ring_buffer.c >> @@ -125,7 +125,7 @@ int perf_output_begin(struct perf_output_handle *handle, >> if (unlikely(!rb)) >> goto out; >> >> - if (unlikely(!rb->nr_pages)) >> + if (unlikely(rb->paused)) >> goto out; > Should we increment rb->lost in this case? Not sure about this. The ring buffer is paused deliberately, shall we consider the events we miss as losted events? However I'll try it in next version. Thank you.