From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: David Ahern <dsahern@gmail.com>,
Namhyung Kim <namhyung@gmail.com>,
Namhyung Kim <namhyung@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Andi Kleen <andi@firstfloor.org>,
Stephane Eranian <eranian@google.com>,
Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)
Date: Mon, 14 Dec 2015 10:38:41 +0100 [thread overview]
Message-ID: <20151214093841.GB30347@gmail.com> (raw)
In-Reply-To: <20151214092613.GL6357@twins.programming.kicks-ass.net>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, Dec 11, 2015 at 08:01:31AM -0700, David Ahern wrote:
> > On 12/11/15 1:11 AM, Ingo Molnar wrote:
> > >
> > >* Namhyung Kim <namhyung@gmail.com> wrote:
> > >
> > >>IIRC David said that thread per cpu seems too much especially on a large system
> > >>(like ~1024 cpu). [...]
> > >
> > >Too much in what fashion? For recording I think it's the fastest, most natural
> > >model - anything else will create cache line bounces.
> >
> > The intrusiveness of perf on the system under observation. I understand
> > there are a lot of factors that go into it.
>
> So I can see some of that, if every cpu has its own thread then every
> cpu will occasionally schedule that thread. Whereas if there were less,
> you'd not have that.
>
> Still, I think it makes sense to implement it, we need the multi-file
> option anyway. Once we have that, we can also implement a per-node
> option, which should be a fairly simple hybrid of the two approaches.
>
> The thing is, perf-record is really struggling on big machines.
>
> And in an unrelated note, I absolutely detest --buildid being the
> default, it makes perf-record blow chunks.
So I'd absolutely _love_ to split up the singular perf.data into a hierarchy of
files in a .perf directory, with a structure like this (4-core system):
.perf/cmdline
.perf/features
.perf/evlist
.perf/ring_buffers/cpu0/raw.trace
.perf/ring_buffers/cpu1/raw.trace
.perf/ring_buffers/cpu2/raw.trace
.perf/ring_buffers/cpu3/raw.trace
...
I.e. the current single file format of perf.data would be split up into individual
files. Each CPU would get its own trace file output - any sorting and ordering
would be done afterwards. 'perf record' itself would never by default have to do
any of that, it's a pure recording session.
'perf archive' would still create a single file to make transport between machines
easy.
perf.data.old would be replaced by a .perf.old directory or so.
Debugging would be easier too I think, as there's no complex perf data format
anymore, it's all in individual (typically text, or binary dump) files in the
.perf directory.
This would solve all the scalability problems - and would make the format more
extensible and generally more accessible as well.
What do you think?
Thanks,
Ingo
next prev parent reply other threads:[~2015-12-14 9:38 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 7:53 [PATCHSET 00/16] perf top: Add multi-thread support (v1) Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 01/16] perf top: Delete half-processed hist entries when exit Namhyung Kim
2015-12-10 9:55 ` 平松雅巳 / HIRAMATU,MASAMI
2015-12-10 18:57 ` Arnaldo Carvalho de Melo
2015-12-14 8:15 ` [tip:perf/core] " tip-bot for Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 02/16] perf top: Fix and cleanup perf_top__record_precise_ip() Namhyung Kim
2015-12-10 19:04 ` Arnaldo Carvalho de Melo
2015-12-11 2:27 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 03/16] perf top: Factor out warnings about kernel addresses and symbols Namhyung Kim
2015-12-10 19:07 ` Arnaldo Carvalho de Melo
2015-12-14 1:44 ` Namhyung Kim
2015-12-14 2:02 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 04/16] perf top: Factor out warnings in perf_top__record_precise_ip() Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 05/16] perf top: Show warning messages in the display thread Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 06/16] perf top: Get rid of access to hists->lock in perf_top__record_precise_ip() Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 07/16] perf hists: Pass hists struct to hist_entry_iter struct Namhyung Kim
2015-12-13 23:15 ` Jiri Olsa
2015-12-14 1:45 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 08/16] perf tools: Export a couple of hist functions Namhyung Kim
2015-12-13 23:17 ` Jiri Olsa
2015-12-10 7:53 ` [PATCH/RFC 09/16] perf tools: Update hist entry's hists pointer Namhyung Kim
2015-12-13 23:23 ` Jiri Olsa
2015-12-13 23:28 ` Jiri Olsa
2015-12-14 1:51 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 10/16] perf hist: Add events_stats__add() and hists__add_stats() Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 11/16] perf top: Implement basic parallel processing Namhyung Kim
2015-12-14 9:23 ` Jiri Olsa
2015-12-14 9:35 ` Jiri Olsa
2015-12-15 2:08 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 12/16] perf tools: Reduce lock contention when processing events Namhyung Kim
2015-12-14 8:43 ` Jiri Olsa
2015-12-15 2:03 ` Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 13/16] perf top: Protect the seen list using mutex Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 14/16] perf top: Separate struct perf_top_stats Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 15/16] perf top: Add --num-thread option Namhyung Kim
2015-12-10 7:53 ` [PATCH/RFC 16/16] perf tools: Skip dso front cache for multi-threaded lookup Namhyung Kim
2015-12-10 8:01 ` [PATCHSET 00/16] perf top: Add multi-thread support (v1) Ingo Molnar
2015-12-10 8:49 ` Namhyung Kim
2015-12-11 8:11 ` Ingo Molnar
2015-12-11 15:01 ` David Ahern
2015-12-14 1:12 ` Namhyung Kim
2015-12-14 9:26 ` Peter Zijlstra
2015-12-14 9:38 ` Ingo Molnar [this message]
2015-12-14 14:55 ` David Ahern
2015-12-14 16:26 ` Arnaldo Carvalho de Melo
2015-12-14 16:41 ` Peter Zijlstra
2015-12-14 17:52 ` Arnaldo Carvalho de Melo
2015-12-14 16:38 ` Namhyung Kim
2015-12-14 16:56 ` Peter Zijlstra
2015-12-14 17:11 ` Namhyung Kim
2015-12-14 14:46 ` David Ahern
2015-12-14 17:06 ` Namhyung Kim
2015-12-14 17:54 ` Arnaldo Carvalho de Melo
2015-12-14 16:25 ` Namhyung Kim
2015-12-14 16:44 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151214093841.GB30347@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=andi@firstfloor.org \
--cc=dsahern@gmail.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@gmail.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).