Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753874AbbKYH4x (ORCPT ); Wed, 25 Nov 2015 02:56:53 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:60521 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753301AbbKYH4v (ORCPT ); Wed, 25 Nov 2015 02:56:51 -0500 Message-ID: <5655684A.5080707@huawei.com> Date: Wed, 25 Nov 2015 15:50:34 +0800 From: Yunlong Song User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Ahern , , , , CC: , , , , , , , , , , , , 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> <1448373632-8806-2-git-send-email-yunlong.song@huawei.com> <56547D01.8020606@gmail.com> In-Reply-To: <56547D01.8020606@gmail.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.74.205] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.565569B8.00D2,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: 76b47648a109b588cd5f3228216a19b1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2237 Lines: 35 On 2015/11/24 23:06, David Ahern wrote: > > So you are basically ignoring all samples until SIGUSR2 is received. That means the resulting data file will have limited history of task events for example. And for other events the quantity is random as to when the mmaps were last scanned. > > Your cover letter mentioned my code "just makes some count when the signal triggers perf sched, with no sample recording and has nothing to do with perf.data". That is not correct. If you look at the perf-daemon code I pointed you to it processes task events as they are received and saves the last N-events after time sorting (limited by memory or time). When a signal is received it processes the saved events and dumps them to stdout versus writing a perf.data file. > > David > Hi, David, Yes, I know that your sched daemon can store and print info when the signal triggers, however, what I mean 'makes some count' is: sched daemon parses and processes the events to extract the tracing info related with sched, rather than a general use of perf.data like "perf script", "perf report", "perf data convert --to-ctf", etc. And what I mean 'no sample recording and has nothing to do with perf.data' is: when perf receives a signal, sched daemon uses timehist_print_summary and timehist_pstree to record those tracing info related with sched to a new file rather than the raw perf event records in the perf.data. We can not use those files generated by sched daemon to enjoy the strong functions like how perf.data can be used in "perf script", "perf report", "perf data convert --to-ctf", etc. Sched daemon is good, but it is carefully designed for specific use of perf sched. In general case of perf record, with snapshot mode, we still want a perf.data as before. Your sched daemon concurrently does the work of storing and sched-parsing action for each signal trigger. To get a general style of perf.data, the sched-parsing semantic action may have to be removed. -- Thanks, Yunlong Song -- 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/