From: "Liang, Kan" <kan.liang@intel.com>
To: David Ahern <dsahern@gmail.com>, Andi Kleen <andi@firstfloor.org>
CC: Arnaldo Carvalho de Melo <acme@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Huang, Ying" <ying.huang@intel.com>
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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1858
Lines: 50

> 
> 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

--
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/