[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180914170236.y5olkroo7ydthtvi@two.firstfloor.org>
Date: Fri, 14 Sep 2018 10:02:36 -0700
From: Andi Kleen <andi@...stfloor.org>
To: Jiri Olsa <jolsa@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andi Kleen <andi@...stfloor.org>,
Alexey Budankov <alexey.budankov@...ux.intel.com>
Subject: Re: [RFCv2 00/48] perf tools: Add threads to record command
> In big picture this patchset adds perf record --threads
> option that allows to create threads in following modes:
>
> 1) single thread mode (current)
>
> $ perf record ...
> $ perf record --threads=1 ...
>
> - all maps are read/stored under process thread
>
> 2) mode with specific (X) number of threads
>
> $ perf record --threads=X ...
>
> - maps are spread equaly among threads
>
> 3) mode that creates thread for every monitored memory map
>
> $ perf record --threads ...
>
> - which in perf record is equal to number of CPUs, and
> it pins each thread to its map's cpu:
We need some way to flush data on a different thread than
what is processing the perf data, so essentially more threads than
CPUs. Something like this is needed for PT where even a single CPU can
generate so much data that it may take longer and longer to flush. You end up
with long gaps in the PT collection then because PT stays disabled
while the flushing happens on the same thread. If it was done
in the background in another thread these gaps would be much smaller.
Of course if Linux would finally get real file system AIO that wouldn't
be needed ...
-Andi
Powered by blists - more mailing lists