lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBQTpt0dhinJZc+mJ-JNvkU2M9DVx1G65ngWxZxk-eGBVA@mail.gmail.com>
Date:   Mon, 4 Feb 2019 14:44:37 -0800
From:   Stephane Eranian <eranian@...gle.com>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Jiri Olsa <jolsa@...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>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andi Kleen <ak@...ux.intel.com>
Subject: Re: [RFC/PATCH 00/14] perf record: Add support to store data in directory

Jiri,

While you're looking at the output format, I think it would be good
time to simplify the code handling perf.data file.
Today, perf record can emit in two formats: file mode or pipe mode.
This adds complexity in the code and
is error prone as the file mode path is tested more than the pipe mode
path. We have run into multiple issues with
the pipe mode in recent years. There is no real reason why we need to
maintain two formats. If I recall, the pipe format
was introduced because on pipes you cannot lseek to update the headers
and therefore some of the information present as tables
updated on the fly needed to be generated as pseudo records by the
tool. I believe that the pipe format covers all the needs and could
supersede the file mode format. That would simplify code in perf
record and eliminate the risk of errors when new headers
are introduced.

Related to your effort to make perf record multi-threaded, I was
wondering how this would impact pipe mode.
Could you explain?

Thanks.


On Mon, Feb 4, 2019 at 12:28 PM Jiri Olsa <jolsa@...hat.com> wrote:
>
> On Mon, Feb 04, 2019 at 12:05:38PM -0800, Stephane Eranian wrote:
>
> SNIP
>
> > > > > > >
> > > > > > > [jolsa@...va perf]$ ll result_1/
> > > > > > > total 348
> > > > > > > -rw-------. 1 jolsa jolsa 27624 Feb  4 11:35 data.0
> > > > > > > -rw-------. 1 jolsa jolsa 56672 Feb  4 11:35 data.1
> > > > > > > -rw-------. 1 jolsa jolsa 30824 Feb  4 11:35 data.2
> > > > > > > -rw-------. 1 jolsa jolsa 49136 Feb  4 11:35 data.3
> > > > > > > -rw-------. 1 jolsa jolsa 22712 Feb  4 11:35 data.4
> > > > > > > -rw-------. 1 jolsa jolsa 53392 Feb  4 11:35 data.5
> > > > > > > -rw-------. 1 jolsa jolsa 43352 Feb  4 11:35 data.6
> > > > > > > -rw-------. 1 jolsa jolsa 46688 Feb  4 11:35 data.7
> > > > > > > -rw-------. 1 jolsa jolsa  9068 Feb  4 11:35 header
> > > > > >
> > > > > > Awesome. What do you think about having it like this:
> > > > > >
> > > > > >   $ perf record --output result_1.data ... - writes data to a file
> > > > > >
> > > > > >   $ perf record --dir result_1 ... - or even
> > > > > >   $ perf record --output_dir result_1 ... - writes data into a directory
> > > > > >
> > > > > > IMHO, this interface is simpler for a user.
> > > > >
> > > > > yep, seems more convenient.. I'll add it
> > > > >
> > > > But what happens if you do: perf record -o foo --output_dir foo.d?
> > >
> > > Should fail, i.e. either you use single-file or directory output, I
> > > think.
> > >
> > Agreed
>
> ok, will do that
>
> thanks,
> jirka

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ