lkml.org 
[lkml]   [2017]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V3 0/6] event synthesization multithreading for perf record

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

\
 
 \ /
  Last update: 2017-10-23 13:49    [W:0.117 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site