From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751819AbdADLqm (ORCPT ); Wed, 4 Jan 2017 06:46:42 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51674 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751379AbdADLqk (ORCPT ); Wed, 4 Jan 2017 06:46:40 -0500 Subject: Re: [PATCH v4 0/3] perf: add support for analyzing events for containers To: Krister Johansen References: <148182699546.5314.279803283347257825.stgit@hbathini.in.ibm.com> <20161229014138.GB2341@templeofstupid.com> <40b222dc-5149-4f82-4d5e-6a8d188a6a35@linux.vnet.ibm.com> <20170104090459.GB3009@templeofstupid.com> Cc: ast@fb.com, peterz@infradead.org, lkml , acme@kernel.org, alexander.shishkin@linux.intel.com, mingo@redhat.com, daniel@iogearbox.net, rostedt@goodmis.org, Ananth N Mavinakayanahalli , ebiederm@xmission.com, sargun@sargun.me, Aravinda Prasad , brendan.d.gregg@gmail.com From: Hari Bathini Date: Wed, 4 Jan 2017 17:15:02 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170104090459.GB3009@templeofstupid.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17010411-0052-0000-0000-00000206098B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17010411-0053-0000-0000-0000078A649D Message-Id: <1d75e250-62dd-6d5b-2644-a79d208b2875@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-04_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701040191 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 04 January 2017 02:34 PM, Krister Johansen wrote: > On Tue, Jan 03, 2017 at 04:57:54PM +0530, Hari Bathini wrote: >> On Thursday 29 December 2016 07:11 AM, Krister Johansen wrote: >>> On Fri, Dec 16, 2016 at 12:06:55AM +0530, Hari Bathini wrote: >>>> 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. >>> Why choose cgroups when the kernel dispenses namespace-unique >>> identifiers. Cgroup membership can be arbitrary. Moreover, cgroup and >> Agreed. But doesn't that hold for any other namespace or a combination >> of namespaces as well? > I guess that's part of my concern. There is no container-unique > identifier on the system, since the notion of containers is a construct > of higer-level software. You're depending on the fact that some popular > container software packages put their processes in separate cgroups. > Some of the stranger problems I've debugged with containers involve > abuses of nsenter(1) and shared subtrees. In cases like that, if you > filter by cgroup you may miss other interfering processes that are in > one or more of the namespaces associated with the container, but not its > cgroup. It's possible I misunderstood. Is the cgroup id being used to > filter events, or just for display purposes? All namespaces info for all threads is captured in perf.data with PERF_RECORD_NAMESPACES events, which can be used for post processing. We used cgroup namespace's id in patch 3/3 for reporting, which can be improved later.. Thanks Hari