All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Liang, Kan" <kan.liang@intel.com>,
	"acme@kernel.org" <acme@kernel.org>,
	"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: Wed, 25 Oct 2017 11:00:34 +0200	[thread overview]
Message-ID: <20171025090034.GA27028@krava> (raw)
In-Reply-To: <20171024125944.uswroptykcqrgjox@gmail.com>

On Tue, Oct 24, 2017 at 02:59:44PM +0200, Ingo Molnar wrote:
> 
> * 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
> 
> etc.
> 
> Is this how you implemented it?

in a way ;-) but I made it more generic and let record create just
few threads and let them share cpu subset.. and so there was no binding

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

ok it's easy to add binding now and 1:1 thread:cpu mapping.. I'll retry

jirka

  parent reply	other threads:[~2017-10-25  9:00 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
2017-10-25  9:00           ` Jiri Olsa [this message]
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=20171025090034.GA27028@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=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.