Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754303AbbFMPGn (ORCPT ); Sat, 13 Jun 2015 11:06:43 -0400 Received: from mga02.intel.com ([134.134.136.20]:9252 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751394AbbFMPGh convert rfc822-to-8bit (ORCPT ); Sat, 13 Jun 2015 11:06:37 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,608,1427785200"; d="scan'208";a="507702765" From: "Liang, Kan" To: David Ahern , 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 Thread-Topic: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing Thread-Index: AQHQo44i3glIe3h0sEG/9i/L0QJfWp2m0lUAgAAU7wCAADmvgIAAYMUAgAFtkPD//5AIgIAAk2vg//+KeQCAAJJsMP//j0eAABDMbwAAAeZYAAAlJJ1g Date: Sat, 13 Jun 2015 15:06:31 +0000 Message-ID: <37D7C6CF3E00A74B8858931C1DB2F07701876EDB@SHSMSX103.ccr.corp.intel.com> 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> <557BB084.8030800@gmail.com> In-Reply-To: <557BB084.8030800@gmail.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1625 Lines: 42 > > 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? I once wanted to simplify the case. So I limited the perf record for one thread and sampled the test at very beginning. So we can see the processing time. But it makes things more complicate and confusing. :( Anyway, both system-wide-monitorings have this issue. The system-wide monitorings include perf top and perf record -a. Thanks, Kan > > David -- 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/