From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>, "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>,
"namhyung@kernel.org" <namhyung@kernel.org>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"Hunter, Adrian" <adrian.hunter@intel.com>,
"ak@linux.intel.com" <ak@linux.intel.com>
Subject: Re: [PATCH V3 0/6] event synthesization multithreading for perf record
Date: Tue, 24 Oct 2017 10:08:49 -0300 [thread overview]
Message-ID: <20171024130849.GD7045@kernel.org> (raw)
In-Reply-To: <20171024125944.uswroptykcqrgjox@gmail.com>
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.
Later, the same thing happens at processing time, this time we'll have
contention to access global thread state, the need for rounds of
PERF_SAMPLE_TIME based ordering, like what we have now in the
tools/perf/util/ordered-events.[ch] code, etc.
This works for both 'report', 'script', 'top', 'trace', etc, as is
basically the model we already have. All the work that was done for
refcounting the thread, map, etc as well as locking those rbtrees would
finally be taken full advantage of.
- Arnaldo
> etc.
>
> Is this how you implemented it?
> If the threads in the thread pool are just free-running then the scheduler might
> not migrate it to the 'right' CPU that is streaming the perf events and there will
> be a lot of cross-talking between CPUs.
>
> Inherited events (default 'perf record') is tougher.
>
> Thanks,
>
> Ingo
next prev parent reply other threads:[~2017-10-24 13:13 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 [this message]
2017-10-24 13:25 ` Ingo Molnar
2017-10-25 2:35 ` Namhyung Kim
2017-10-25 9:02 ` Jiri Olsa
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=20171024130849.GD7045@kernel.org \
--to=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=jolsa@redhat.com \
--cc=kan.liang@intel.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 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).