From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754552AbbFLWlp (ORCPT ); Fri, 12 Jun 2015 18:41:45 -0400 Received: from mga09.intel.com ([134.134.136.24]:40308 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751362AbbFLWln convert rfc822-to-8bit (ORCPT ); Fri, 12 Jun 2015 18:41:43 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,605,1427785200"; d="scan'208";a="745824636" 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//j0eAABDMbwD//5DlgP//ah+A Date: Fri, 12 Jun 2015 22:41:36 +0000 Message-ID: <37D7C6CF3E00A74B8858931C1DB2F07701876DE9@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> <557B4691.7090304@gmail.com> In-Reply-To: <557B4691.7090304@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 > > On 6/12/15 2:39 PM, Liang, Kan wrote: > > Here are the test results. > > Please note that I get "synthesized threads took..." after the test case > exit. > > It means both way have the same issue. > > Got it. So what you really mean is launching perf on an already running > process perf never finishes initializing. There are several types of problems > like this. For example on a sparc system with a 1024 cpus if I launch perf > (top or record) after starting a kernel build with make -j > 1024 the build finishes before perf starts collecting samples. ie., it never > finishes walking /proc until the build is complete. task_diag does not solve > that problem either and in general the procps tools can't handle it either > (ps or top for example). > We should not stop using system wide perf top/record just because there are some threads which have huge/growing maps. The maps information is not critical for sampling. If task_diag does not solve this problem, I think we still need a time out to force stop endless mmap processing. It's the simplest working solution so far. > For your test case what happens if you run: > perf record -- test-app > > Is perf overloaded with mmap samples? does it keep up or do you have to > jack the mmap size (-m arg)? No. synthesize_threads will not be called unless you specify the process/threads/cpu. (Please refer to __machine__synthesize_threads.) So it works well. perf record -- ./run case-small-allocs [ perf record: Woken up 3844 times to write data ] [ perf record: Captured and wrote 1001.897 MB perf.data (26259688 samples) ] Thanks, Kan