* kan.li...@intel.com <kan.li...@intel.com> 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
