* Jiri Olsa <jo...@redhat.com> wrote:
> On Fri, Sep 14, 2018 at 11:29:10AM +0900, Namhyung Kim wrote:
> > On Thu, Sep 13, 2018 at 07:10:35PM +0300, Alexey Budankov wrote:
> > > Hi,
> >
> > Hello,
> >
> > >
> > > On 13.09.2018 15:54, Jiri Olsa wrote:
> > > > hi,
> > > > sending *RFC* for threads support in perf 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:
> > > >
> > > > 4) TODO - NUMA aware threads/maps separation
> > > > ...
> > > >
> > > > The perf.data stays as a single file.
> >
> > I'm not sure we really need to keep it as a single file. As it's a
> > kind of big changes, we might consider breaking compatibility and use
> > a directory structure.
>
> moving the files into the perf.data at the end is actualy
> not a lot code.. and I think it's one of the 'small' things
> that make this feature more user friendly
So the user shouldn't really care about the structure of the file when most
uses of perf
tooling, and 'single file' versus 'single directory' has similar usability IMHO.
When moving across machines it's recommended to use 'perf archive' anyway,
which already
creates a tarball that includes debuginfo and other context.
In fact keeping the files separate has scalability advantages for 'perf report'
and similar
parsing tools: they could read all the streams in a per-CPU fashion already,
from the very
beginning.
BTW., random annoyance bugreport, for me 'perf archive' is spewing a ton of
these messages:
$ perf archive
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
...
unwind: target platform=x86 is not supported
unwind: target platform=x86 is not supported
Now please run:
$ tar xvf perf.data.tar.bz2 -C ~/.debug
wherever you need to run 'perf report' on.
$ perf version
perf version 4.19.rc2.gcb48b6
That message is repeated 7,200 times (!) and immediately nuked my terminal
history. :-/
Even if we want to emit that warning (we really shouldn't unless it's important
for the user to
know), there's no reason to print thousands of messages to stderr.
Thanks,
Ingo
