From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932571AbbCYSVF (ORCPT <rfc822;w@1wt.eu>);
	Wed, 25 Mar 2015 14:21:05 -0400
Received: from mail-wi0-f179.google.com ([209.85.212.179]:33355 "EHLO
	mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753783AbbCYSU6 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 25 Mar 2015 14:20:58 -0400
Date: Wed, 25 Mar 2015 19:20:52 +0100
From: Ingo Molnar <mingo@kernel.org>
To: David Ahern <david.ahern@oracle.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>, linux-kernel@vger.kernel.org,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>, Jiri Olsa <jolsa@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Stephane Eranian <eranian@google.com>,
        Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCH] perf record: Allow poll timeout to be specified
Message-ID: <20150325182052.GA8938@gmail.com>
References: <1427213388-127148-1-git-send-email-david.ahern@oracle.com>
 <20150324161210.GA8661@gmail.com>
 <20150324212120.GA12599@kernel.org>
 <20150325091147.GA1565@gmail.com>
 <20150325121425.GA13759@kernel.org>
 <5512C903.6070905@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5512C903.6070905@oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* David Ahern <david.ahern@oracle.com> wrote:

> On 3/25/15 6:14 AM, Arnaldo Carvalho de Melo wrote:
> >If David doesn't come up with something I'll probably will, as making
> >'trace' use the ordered_samples, like 'perf top' does (initially with
> >some arbitrary reasonable poll timeout value), is a low hanging fruit to
> >get those multi-CPU tracepoints sorted until I get something better in
> >place...
> 
> I have thought about it. It needs to be an adaptive algorithm:
> 1. start at 100 msec.
> 2. Read the maps. How much data are there (not events, but data size)? 3.
> Adjust poll timeout up or down with some heuristic -- maybe something
> similar to the algorithm perf-top uses for removing entries from the
> histograms.
> 
> That said, I still thinking giving the user control is not a crazy idea.

The user has absolutely zero control over the rate of data and about 
what the ideal refresh rate would be! So this really should be solved 
in software and automatically.

'try to tweak this parameter up and down until the tool is usable' is 
a really, really poor user interface concept ...

Thanks,

	Ingo