Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753433AbbKYMzP (ORCPT ); Wed, 25 Nov 2015 07:55:15 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:12897 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751895AbbKYMzN (ORCPT ); Wed, 25 Nov 2015 07:55:13 -0500 Message-ID: <5655AF89.8070907@huawei.com> Date: Wed, 25 Nov 2015 20:54:33 +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: Yunlong Song , , , , , , , , , , , , , , , , Subject: Re: [PATCH] perf record: Add snapshot mode support for perf's regular events References: <1448373632-8806-1-git-send-email-yunlong.song@huawei.com> <20151125092728.GZ17308@twins.programming.kicks-ass.net> <565582E0.7070202@huawei.com> <20151125122038.GA17308@twins.programming.kicks-ass.net> In-Reply-To: <20151125122038.GA17308@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.0A020203.5655AFA3.00B1,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: b69205be601fd20bb2d37d39c16b15cf Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1739 Lines: 38 On 2015/11/25 20:20, Peter Zijlstra wrote: > On Wed, Nov 25, 2015 at 05:44:00PM +0800, Wangnan (F) wrote: >> >> On 2015/11/25 17:27, Peter Zijlstra wrote: >>> On Tue, Nov 24, 2015 at 10:00:31PM +0800, Yunlong Song wrote: >>>> In our patch, we create and maintain a user space ring buffer to store >>>> perf's tracing info, instead of directly writing to perf.data file as >>>> before. In snapshot mode, only a SIGUSR2 signal can trigger perf to dump >>>> the tracing info currently stored in the user space ring buffer to >>>> perf.data file. >>> I would very much like to first fix the perf overwrite mode: see >>> lkml.kernel.org/r/20151023151205.GW11639@twins.programming.kicks-ass.net >> I think they can be done in parallel. We can first do something with >> tracking events and perf's output file, and wait for kernel level >> overwrite mode fixed, then decide whether to implement perf's own >> ringbuffer. > That seems backwards; why would you ever want to endlessly copy the > events if you're not going to use them? I agree that we need to fixing overwrite mode. However, user space ringbuffer can be more flexible. for example, dynamically shrinking and expansion. It would be hard in kernel I think, and I'm not sure how much flexibility we need. Doing things in kernel always more difficult than in userspace. But yes, we can do that userspace ring buffer when we really need it. At very first we can start working on perf side and assume overwrite mode is ready. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/