From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756769AbbFPP51 (ORCPT ); Tue, 16 Jun 2015 11:57:27 -0400 Received: from mail-ob0-f171.google.com ([209.85.214.171]:32840 "EHLO mail-ob0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751187AbbFPP5S (ORCPT ); Tue, 16 Jun 2015 11:57:18 -0400 Message-ID: <5580475B.10704@gmail.com> Date: Tue, 16 Jun 2015 09:57:15 -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: Arnaldo Carvalho de Melo CC: "Liang, Kan" , Andi Kleen , "linux-kernel@vger.kernel.org" , "Huang, Ying" Subject: Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing References: <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> <20150616151159.GF10374@kernel.org> In-Reply-To: <20150616151159.GF10374@kernel.org> 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 On 6/16/15 9:11 AM, Arnaldo Carvalho de Melo wrote: > Then, that being said, having a sane upper limit on the time for > processing those events makes the tool more robust and allows it to do > most of its work, just samples for the maps not synthesized will fail to > get resolved to symbols/DSOs. If you are going to use timeouts then you need a sane upper limit on walking /proc altogether as well. i.e, one time limit for individual proc files (ie, time limit per task), and one for all of /proc (i.e, time limit for all of synthesized_threads). What is a reasonable time limit for each? Will it be configurable or hardcoded? If perf aborts data collection for either a case the user should get a warning. > > For those cases we should, during synthesizing, do both what Kan did in > his patch, i.e. emit a log warning with the COMM/PID that we are > truncating /proc/PID/maps parsing, and increment a counter that, just > after we finish synthesizing we should report, in a similar way as we > do in perf_session__warn_about_errors() after processing events, > something like: > > +--------------------------------------------------------+ > | %d map information files for pre-existing threads were | > | not processed, if there are samples for addresses they | > | will not be resolved, you may find out which are these | > | threads by running with -v and redirecting the output | > | to a file. | > +--------------------------------------------------------+ > > Ideally, as an extra step, we could flip a flag on the 'struct thread' > where these maps got truncated and add some visual cue to the > hist_entry instances (lines in the top UI). > > Perhaps we should add a per-thread-proc-map-processing timeout parameter > to the synthesizing routines instead of having that hardcoded, i.e. > allow the tool to specify what is reasonable for it, but that wouldn't > be strictly required for a first patch, emitting the dialog box above > after synthesizing, if truncation happened, is. > > Agreed? And then report side there should be a warning as well (record can be done by one person and analysis by another). David