linux-kernel - Re: [RFCv2 00/48] perf tools: Add threads to record command

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: <20180914093344.GA96351@gmail.com>
Date:   Fri, 14 Sep 2018 11:33:44 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andi Kleen <andi@...stfloor.org>, kernel-team@....com
Subject: Re: [RFCv2 00/48] perf tools: Add threads to record command

* Namhyung Kim <namhyung@...nel.org> wrote:

> > > 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.

Agreed - and to make use of the highly scalable Linux VFS implementation we should
attempt to use per CPU file resources as well.

Any cross-CPU contention should stick out like a sore thumb.

> > There is usage of Posix threading API but there is no 
> > its implementation in the patch series, to avoid dependency 
> > on externally coded designs in the core of the tool.
> 
> Do you mean it needs to implement its own threading?  I don't think
> that's what Ingo wanted to.

Yeah, I didn't mean that: every libc hoping to work on Linux implements a pthread API, plus the 
pthread APIs we are using are really just narrow wrappers on top of system calls that were 
written with libc pthread APIs in mind. So it's not a problem to rely on pthreads.h. (And if we 
have trouble with any particular pthread detail we can single out specific functionality and 
not use it or use our own implementation.)

The AIO library is another matter: it's a family of interfaces with complex libc specific 
design choices that cannot be influenced.

I.e. my suggestion was to keep using pthreads APIs like we do today, but not use the libc AIO 
library. Not because there's any problem with glibc AIO: but because basic event flow is a core 
competency of perf that we want to implement ourselves.

Is this clearer?

Thanks,

	Ingo