On 3/24/15 10:12 AM, Ingo Molnar wrote:
* David Ahern <[email protected]> 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!
I knew you were going to say that! ;-)
It's really a function of events coming in not cpus. The number of CPUs
just compounds the problem.
I thought about making perf-record use a 100msec timeout like perf-top,
but that can lead to unnecessary FINISHED_ROUND events in the file and
unnecessary noise/overhead in the record side. On the other hand looking
at scheduler tracepoints, kvm tracepoints, etc -- those can flood in to
the point that even 100msec is too long.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
