From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751257AbbFMEYq (ORCPT ); Sat, 13 Jun 2015 00:24:46 -0400 Received: from mail-pa0-f41.google.com ([209.85.220.41]:33415 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835AbbFMEYj (ORCPT ); Sat, 13 Jun 2015 00:24:39 -0400 Message-ID: <557BB084.8030800@gmail.com> Date: Fri, 12 Jun 2015 22:24:36 -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> <557B3309.4080002@gmail.com> <37D7C6CF3E00A74B8858931C1DB2F07701876D60@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F07701876D60@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 coming back to this ... On 6/12/15 2:39 PM, Liang, Kan wrote: >>> 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? > > I just tried to simplify the issue for perf record. So you may noticed that > I only read one thread. There are several threads in the system. > Also, I do the perf record test when starting the test case. > The proc file is not that big. > For perf top, it will monitor whole system. So it never finishes. If the proc file is not that big for perf-record why is it a problem for perf-top? Both should only be reading the maps file for the thread group leader once and after it is processed getting MMAP events for changes. Why do you say perf-top can't handle it but perf-record can? David