[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150325182052.GA8938@gmail.com>
Date: Wed, 25 Mar 2015 19:20:52 +0100
From: Ingo Molnar <mingo@...nel.org>
To: David Ahern <david.ahern@...cle.com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
linux-kernel@...r.kernel.org,
Frederic Weisbecker <fweisbec@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Stephane Eranian <eranian@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH] perf record: Allow poll timeout to be specified
* David Ahern <david.ahern@...cle.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists