From: Hari Bathini <hbathini@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: ast@fb.com, lkml <linux-kernel@vger.kernel.org>,
acme@kernel.org, alexander.shishkin@linux.intel.com,
mingo@redhat.com, daniel@iogearbox.net, rostedt@goodmis.org,
Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
ebiederm@xmission.com, sargun@sargun.me,
Aravinda Prasad <aravinda@linux.vnet.ibm.com>,
brendan.d.gregg@gmail.com
Subject: Re: [PATCH v2 1/2] perf: add container identifier entry in perf sample data
Date: Fri, 2 Sep 2016 19:25:31 +0530 [thread overview]
Message-ID: <58edcf4e-80d4-3b0e-773d-29d28070392d@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160901090941.GO10153@twins.programming.kicks-ass.net>
On Thursday 01 September 2016 02:39 PM, Peter Zijlstra wrote:
> On Tue, Aug 30, 2016 at 09:57:02PM +0530, Hari Bathini wrote:
>> Currently, there is no mechanism to filter events based on containers.
>> perf -G can be used, but it will not filter events for the containers
>> created after perf is invoked, making it difficult to assess/analyze
>> performance issues of multiple containers at once. This limitation can
>> be overcome, if there is a standard kernel identifier for containers.
>>
>> This patch introduces a container identifier entry field in perf sample
>> data to identify or distinguish sample data of different containers. It
>> uses the cgroup namespace inode number of a given task as it's container
>> identifier (cid). Alternatively, inode number of pid namespace can also
>> be used as cid. This patch assumes each container is created with it's
>> own cgroup namespace.
Hi Peter,
> I'm thinking this value is mostly the same for tasks, just like COMM and
I think so, too. Namespaces aren't changed that often for tasks...
> MMAP. Could we therefore not emit (sideband) events whenever a task
> changes namespace and get the same information but with tons less data?
You mean, something like PERF_RECORD_NAMESPACE that
emits events on fork, clone, setns..?
> That also gives the possibility of recording all namespaces, not just
> the one.
True. If we record all namespaces, container identifier interpretation
can be left to the userspace to decide, which is much more flexible...
Thanks
Hari
next prev parent reply other threads:[~2016-09-02 13:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-30 16:27 [PATCH v2 1/2] perf: add container identifier entry in perf sample data Hari Bathini
2016-08-30 16:27 ` [PATCH v2 2/2] perf tool: add container identifier entry related changes Hari Bathini
2016-09-01 9:09 ` [PATCH v2 1/2] perf: add container identifier entry in perf sample data Peter Zijlstra
2016-09-02 13:55 ` Hari Bathini [this message]
2016-09-02 13:59 ` Peter Zijlstra
2016-09-02 16:55 ` Hari Bathini
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=58edcf4e-80d4-3b0e-773d-29d28070392d@linux.vnet.ibm.com \
--to=hbathini@linux.vnet.ibm.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=ananth@linux.vnet.ibm.com \
--cc=aravinda@linux.vnet.ibm.com \
--cc=ast@fb.com \
--cc=brendan.d.gregg@gmail.com \
--cc=daniel@iogearbox.net \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sargun@sargun.me \
/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).