Re: heads up/RFC: 'perf trace' using ordered_events
From: David Ahern
Date: Tue Mar 10 2015 - 10:25:37 EST
On 3/10/15 12:06 AM, Namhyung Kim wrote:
On Mon, Mar 09, 2015 at 10:21:35AM -0300, Arnaldo Carvalho de Melo wrote:
For trace I need to take advantage of the fact that each mmap is ordered
already and then just sort by the timestamp in the mmap head, etc.
In retrospect, the perf.data file should have kept that ordering, i.e.
have one file per mmap, that would be saved in parallel, without any of
those PERF_RECORD_FINISHED_ROUND records.
But I have to experiment with that, leaving the existing code around to
deal with older files.
It seems like what you said is almost same as my multi-thread work.
It saves data files per mmap and then merges them with an index
table so that they can be processed in parallel.
I think you and Jiri both have worked on saving a file per mmap. Where
does that stand? I would like to try it out.
With the 1024 cpu systems I am seeing 5GB files in 1 second runs and
perf is not handling it well. The perf-script/perf-report (stdio) will
'hang' for 45 minutes munging through the file. I have to connect gdb
from time to time to verify it is making progress (file_offset is
increasing). I believe what happens is that there is 'no round' -- it
has to process all mmaps (1024 cpus and 6 or 7 events) through the
ordered events queue before it can push out results. I need to look at
that once I figure out the task scheduler problem.
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/