From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752586AbbCYMje (ORCPT ); Wed, 25 Mar 2015 08:39:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35520 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752247AbbCYMja (ORCPT ); Wed, 25 Mar 2015 08:39:30 -0400 Date: Wed, 25 Mar 2015 13:38:55 +0100 From: Jiri Olsa To: David Ahern Cc: acme@kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Frederic Weisbecker , Peter Zijlstra , Jiri Olsa , Namhyung Kim , Stephane Eranian , Adrian Hunter Subject: Re: [PATCH] perf record: Allow poll timeout to be specified Message-ID: <20150325123855.GC26966@krava.brq.redhat.com> References: <1427213388-127148-1-git-send-email-david.ahern@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1427213388-127148-1-git-send-email-david.ahern@oracle.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 24, 2015 at 12:09:48PM -0400, David Ahern wrote: > Record currently wakes up based on watermarks to read events from the mmaps and > write them out to the file. The result is a file that can have large blocks of > events per mmap before a finished round event is added to the stream. This in > turn affects the quantity of events that have to be passed through the ordered > events queue before results can be displayed to the user. For commands like > perf-script this can lead to long unnecessarily long delays before a user gets > output. Large systems (e.g, 1024 cpus) further compound this effect. I have seen > instances where I have to wait 45 minutes for perf-script to process a 5GB file > before any events are shown. so you have pipe to perf script, right? > > This patch adds an option to perf-record to allow a user to specify the > poll timeout in msec. For example using 100 msec timeouts similar to perf-top > means the mmaps are traversed much more frequently leading to a smoother > analysis side. there's also the '--no-buffering' option that sets: attr->watermark = 0; attr->wakeup_events = 1; but that's just the other edge, which is not what you'd want I think it's good to have user side configurable as well Acked-by: Jiri Olsa thanks, jirka