[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <52383a1b-39aa-c9db-89bc-2dba5369489b@linux.vnet.ibm.com>
Date: Fri, 16 Dec 2016 23:56:40 +0530
From: Hari Bathini <hbathini@...ux.vnet.ibm.com>
To: Alban Crequy <alban.crequy@...il.com>
Cc: ananth@...ibm.com, daniel@...earbox.net,
Linux Containers <containers@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
acme@...nel.org, alexander.shishkin@...ux.intel.com,
mingo@...hat.com, paulus@...ba.org, rostedt@...dmis.org,
aravinda@...ux.vnet.ibm.com, kernel@...p.com,
Alexander Viro <viro@...iv.linux.org.uk>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH v4 0/3] perf: add support for analyzing events for
containers
Hi Alban,
On Friday 16 December 2016 05:44 PM, Alban Crequy wrote:
> Hi,
>
>> Currently, there is no trivial mechanism to analyze 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 patch-set overcomes this limitation by using cgroup identifier as
>> container unique identifier. A new PERF_RECORD_NAMESPACES event that
>> records namespaces related info is introduced, from which the cgroup
>> namespace's device & inode numbers are used as cgroup identifier. This
>> is based on the assumption that each container is created with it's own
>> cgroup namespace allowing assessment/analysis of multiple containers
>> using cgroup identifier.
>>
>> The first patch introduces PERF_RECORD_NAMESPACES in kernel while the
>> second patch makes the corresponding changes in perf tool to read this
>> PERF_RECORD_NAMESPACES events. The third patch adds a cgroup identifier
>> column in perf report, which contains the cgroup namespace's device and
>> inode numbers.
> I have a question for the pid namespace: does the new perf event gives
> the pid namespace of the task, or the pid_ns_for_children from the
> nsproxy? From my limited understanding, v4 seems to do the former, as
> opposed to v3.
Ah! How did I miss that?!
> When synthesizing events from /proc/$PID/ns/pid, it cannot take the
> pid_ns_for_children, so I wanted to make sure it is consistent.
>
So, eventually this version sounds like the right way of doing it..?
Thanks
Hari
Powered by blists - more mailing lists