From: Jiri Olsa <jolsa@redhat.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
"Liang, Kan" <kan.liang@intel.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"jolsa@kernel.org" <jolsa@kernel.org>,
"wangnan0@huawei.com" <wangnan0@huawei.com>,
"hekuang@huawei.com" <hekuang@huawei.com>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"Hunter, Adrian" <adrian.hunter@intel.com>,
"ak@linux.intel.com" <ak@linux.intel.com>,
kernel-team@lge.com
Subject: Re: [PATCH V3 0/6] event synthesization multithreading for perf record
Date: Wed, 25 Oct 2017 11:02:02 +0200 [thread overview]
Message-ID: <20171025090201.GF22394@krava> (raw)
In-Reply-To: <20171025023539.GE12785@sejong>
On Wed, Oct 25, 2017 at 11:35:39AM +0900, Namhyung Kim wrote:
> Hi Ingo,
>
> On Tue, Oct 24, 2017 at 03:25:23PM +0200, Ingo Molnar wrote:
> >
> > * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >
> > > Em Tue, Oct 24, 2017 at 02:59:44PM +0200, Ingo Molnar escreveu:
> > > >
> > > > * Jiri Olsa <jolsa@redhat.com> wrote:
> > > >
> > > > > I recently made some changes on threaded record, which are based
> > > > > on Namhyungs time* API, which is needed to read/sort the data afterwards
> > > > >
> > > > > but I wasn't able to get any substantial and constant reduce of LOST events
> > > > > and then I got sidetracked and did not finish, but it's in here:
> > > >
> > > > So, in the context of system-wide profiling, the way that would work best I think
> > > > is the following:
> > > >
> > > > thread #0 binds itself to CPU#0 (via sched_setaffinity) and creates a per-CPU event on CPU#0
> > > > thread #1 binds itself to CPU#1 (via sched_setaffinity) and creates a per-CPU event on CPU#1
> > > > thread #2 binds itself to CPU#2 (via sched_setaffinity) and creates a per-CPU event on CPU#2
> > >
> > > Right, that is how I think it should be done as well, and those will
> > > just dump on separate files, in a per session directory, with an extra
> > > file for the session details, in what is now the header.
> >
> > Yes. Also note how easy to examine such a directory structure is - I'd suggest
> > making all the session details textual eventually. I.e. only the ring-buffers
> > should be binary, the rest should be arch-independent text encoding.
> >
> > It's also very extensible.
>
> Agreed.
>
> Also for multithread work, conversion to directory should be the first
> step IMHO.
yes, but thats what we already have with yours (Namhyung's) HEADER_DATA_INDEX
jirka
next prev parent reply other threads:[~2017-10-25 9:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 20:05 [PATCH V3 0/6] event synthesization multithreading for perf record kan.liang
2017-10-20 20:05 ` [PATCH V3 1/6] perf tools: pass thread info to process function kan.liang
2017-10-20 20:05 ` [PATCH V3 2/6] perf tools: pass thread info in event synthesization kan.liang
2017-10-20 20:05 ` [PATCH V3 3/6] perf tools: expose copyfile_offset() kan.liang
2017-10-20 20:05 ` [PATCH V3 4/6] perf tools: add perf_data_file__open_tmp kan.liang
2017-10-23 16:13 ` Jiri Olsa
2017-10-23 16:19 ` Liang, Kan
2017-10-23 16:26 ` Jiri Olsa
2017-10-23 18:05 ` Liang, Kan
2017-10-24 7:26 ` Jiri Olsa
2017-10-24 7:26 ` Jiri Olsa
2017-10-20 20:05 ` [PATCH V3 5/6] perf record: synthesize event multithreading support kan.liang
2017-10-20 20:05 ` [PATCH V3 6/6] perf record: add option to set the number of thread for event synthesize kan.liang
2017-10-23 11:48 ` [PATCH V3 0/6] event synthesization multithreading for perf record Ingo Molnar
2017-10-23 13:43 ` Liang, Kan
2017-10-23 14:25 ` acme
2017-10-23 18:45 ` Liang, Kan
2017-10-24 9:22 ` Ingo Molnar
2017-10-24 11:47 ` Jiri Olsa
2017-10-24 12:47 ` Liang, Kan
2017-10-24 12:59 ` Ingo Molnar
2017-10-24 13:08 ` Arnaldo Carvalho de Melo
2017-10-24 13:25 ` Ingo Molnar
2017-10-25 2:35 ` Namhyung Kim
2017-10-25 9:02 ` Jiri Olsa [this message]
2017-10-25 9:00 ` Jiri Olsa
2017-10-25 9:07 ` Ingo Molnar
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=20171025090201.GF22394@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=hekuang@huawei.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=wangnan0@huawei.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.