Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933796AbcLMTIR (ORCPT ); Tue, 13 Dec 2016 14:08:17 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60435 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933636AbcLMTIJ (ORCPT ); Tue, 13 Dec 2016 14:08:09 -0500 Subject: Re: [PATCH v3 3/3] perf tool: add cgroup identifier entry in perf report To: "Eric W. Biederman" References: <148156671980.4651.13017595439842763683.stgit@hbathini.in.ibm.com> <148156680219.4651.12310355352884515738.stgit@hbathini.in.ibm.com> <878trkajlc.fsf@xmission.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 , sargun@sargun.me, Aravinda Prasad , brendan.d.gregg@gmail.com From: Hari Bathini Date: Wed, 14 Dec 2016 00:37:52 +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: <878trkajlc.fsf@xmission.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: 16121319-1617-0000-0000-0000018DE27F X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16121319-1618-0000-0000-00004759DC59 Message-Id: <4c6c4754-6a87-56bc-3351-fef699cc57e1@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-12-13_11:,, 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-1609300000 definitions=main-1612130295 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1288 Lines: 34 Hi Eric, On Tuesday 13 December 2016 03:36 AM, Eric W. Biederman wrote: > Hari Bathini writes: > >> This patch introduces a cgroup identifier entry field in perf report to >> identify or distinguish data of different cgroups. It uses the unique >> inode number of cgroup namespace, included in perf data with the new >> PERF_RECORD_NAMESPACES event, as cgroup identifier. With the assumption >> that each container is created with it's own cgroup namespace, this >> allows assessment/analysis of multiple containers at once. > In the large this sounds reasonable. > > The details are wrong. The cgroup id needs to be device > number + inode number, not just inode number. > As the assumption that device number is going to be the same for all namespaces may not stand the test of time, the inode number is not going to be unique, to use as an identifier.. I am thinking of an identifier like the below. This may be OK for now as dev_num & inode_num are 32bit each. identifier = (dev_num << 32 | inode_num) But this may leave us with identifiers that are not unique if dev_num & inode_num are changed to 64bit. Should that be of concern? Do you have any alternate suggestions to come up with unique identifier in such scenario too..? Thanks Hari