Re: [PATCH V3 0/6] event synthesization multithreading for perf record

[Ingo Molnar]

* kan.liang@xxxxxxxxx <kan.liang@xxxxxxxxx> wrote:

> The latency is the time cost of __machine__synthesize_threads or
> its multithreading replacement, record__multithread_synthesize.
> 
> Original:              original single thread synthesize
> With patch(not merge): multithread synthesize without final file merge
>                        (intermediate results for scalability measurement)
> With patch(merge):     multithread synthesize with file merge
>                        (final result)
> 
> - Latency on Knights Mill (272 CPUs)
> 
> Original(s)	With patch(not merge)(s)	With patch(merge)(s)
> 12.7		6.6				7.76
> 
> - Latency on Skylake server (192 CPUs)
> 
> Original(s)	With patch(not merge)(s)	With patch(merge)(s)
> 0.34		0.21				0.23

Ok, I think I mis-understood some aspects of the patch series.

It multi-threads a certain stage of processing (synthesizing), but not the _whole_ 
process of recording events, right?

So I'm wondering, in the context of 'perf record -a' and 'perf top' CPU-granular 
profiling at least (but maybe also in the context of inherited workload 'perf 
record' profiling), could we simply record with per-CPU recording threads created 
early on, which would record into the percpu files quite naturally, which would 
also offer natural multithreading of any 'synthesizing' steps later on?

I.e. instead of multithreading perf record piecemeal wise, why not multithread it 
all - and win big in terms of scalable, low overhead profiling?

	Ingo