Re: [PATCH] perf record: Allow poll timeout to be specified

[Arnaldo Carvalho de Melo]

Em Wed, Mar 25, 2015 at 10:11:47AM +0100, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> > Em Tue, Mar 24, 2015 at 05:12:11PM +0100, Ingo Molnar escreveu:
> > > * David Ahern <david.ahern@xxxxxxxxxx> 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.

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

> > > Please tune the default value (perhaps influenced by N_PROC?) so 
> > > that users will get sane behavior without having to specify this 
> > > option!

> > Isn't this a followup patch? [...]
 
> Will a followup patch be written?

Hope so :-)

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

But what I said is independent of if a followup patch would come or not,
right now we don't have that possibility, with his patch, we do.

Turning it from not possible to possible looks an improvement before we
get it done automatically, and even by then allowing someone to tweak
that value may be useful, no?

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/