Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753453AbbFLT3Y (ORCPT ); Fri, 12 Jun 2015 15:29:24 -0400 Received: from mail-qk0-f181.google.com ([209.85.220.181]:35006 "EHLO mail-qk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752298AbbFLT3R (ORCPT ); Fri, 12 Jun 2015 15:29:17 -0400 Message-ID: <557B3309.4080002@gmail.com> Date: Fri, 12 Jun 2015 13:29:13 -0600 From: David Ahern User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Liang, Kan" , Andi Kleen CC: Arnaldo Carvalho de Melo , "linux-kernel@vger.kernel.org" , "Huang, Ying" Subject: Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing References: <1433922364-22580-1-git-send-email-kan.liang@intel.com> <20150611140614.GC2696@kernel.org> <5579A766.4010504@gmail.com> <20150611184737.GU19417@two.firstfloor.org> <557A28F6.8040603@gmail.com> <37D7C6CF3E00A74B8858931C1DB2F077018767AD@SHSMSX103.ccr.corp.intel.com> <557AFDB1.7030902@gmail.com> <37D7C6CF3E00A74B8858931C1DB2F07701876834@SHSMSX103.ccr.corp.intel.com> <557B16C4.7000000@gmail.com> <37D7C6CF3E00A74B8858931C1DB2F07701876CB2@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F07701876CB2@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1831 Lines: 48 On 6/12/15 12:19 PM, Liang, Kan wrote: >>> [perf]$ sudo ./perf record -e instructions:pp --pid 14560 Reading >>> /proc/14560/maps cost 13.12690599 s ^C[ perf record: Woken up 1 times >>> to write data ] [ perf record: Captured and wrote 0.108 MB perf.data >>> (2783 samples) ] >> >> so perf was able to read the proc file? > > Yes, perf always can read proc file. The problem is that the proc file is > huge and keep growing faster than proc reader. > So perf top do loop in perf_event__synthesize_mmap_events until the > test case exit. I'm confused. How are you getting the above time to read /proc maps if it never finishes? >> Are you sure task_diag is enabled? There is an option under General I >> believe: >> config TASK_DIAG >> bool "Export task/process properties through netlink" >> depends on NET && TASKSTATS >> default n >> help >> Export selected properties for tasks/processes through the >> generic netlink interface. Unlike the proc file system, task_diag >> returns information in a binary format, allows to specify which >> information are required. >> >> Say N if unsure. >> > It works now. for this test case how does perf-record compare between proc and task_diag? You can use my command for both. It defaults to using task_diag and then you can add --no-task_diag to have it read /proc. And as mentioned before it is only setup for 'perf record -a' case. So launch your test program perf record -a -- usleep 1 perf record -a --no-task_diag -- usleep 1 -- 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/