On Mon, Sep 10, 2018 at 11:18:41AM +0200, Ingo Molnar wrote: > > * Alexey Budankov <alexey.budan...@linux.intel.com> wrote: > > > > > Currently in record mode the tool implements trace writing serially. > > The algorithm loops over mapped per-cpu data buffers and stores > > ready data chunks into a trace file using write() system call. > > > > At some circumstances the kernel may lack free space in a buffer > > because the other buffer's half is not yet written to disk due to > > some other buffer's data writing by the tool at the moment. > > > > Thus serial trace writing implementation may cause the kernel > > to loose profiling data and that is what observed when profiling > > highly parallel CPU bound workloads on machines with big number > > of cores. > > Yay! I saw this frequently on a 120-CPU box (hw is broken now). > > > Data loss metrics is the ratio lost_time/elapsed_time where > > lost_time is the sum of time intervals containing PERF_RECORD_LOST > > records and elapsed_time is the elapsed application run time > > under profiling. > > > > Applying asynchronous trace streaming thru Posix AIO API > > (http://man7.org/linux/man-pages/man7/aio.7.html) > > lowers data loss metrics value providing 2x improvement - > > lowering 98% loss to almost 0%. > > Hm, instead of AIO why don't we use explicit threads instead? I think Posix > AIO will fall back > to threads anyway when there's no kernel AIO support (which there probably > isn't for perf > events).
this patch adds the aoi for writing to the perf.data file, reading of events is unchanged > > Per-CPU threading the record session would have so many other advantages as > well (scalability, > etc.). > > Jiri did per-CPU recording patches a couple of months ago, not sure how > usable they are at the > moment? it's still usable, I can rebase it and post a branch pointer, the problem is I haven't been able to find a case with a real performance benefit yet.. ;-) perhaps because I haven't tried on server with really big cpu numbers jirka
