lkml.org 
[lkml]   [2018]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFCv2 00/48] perf tools: Add threads to record command

    * Jiri Olsa <jolsa@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

    \
     
     \ /
      Last update: 2018-09-14 11:40    [W:5.551 / U:0.172 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site