Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933913AbcLMUAA (ORCPT ); Tue, 13 Dec 2016 15:00:00 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:34219 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934262AbcLMT7t (ORCPT ); Tue, 13 Dec 2016 14:59:49 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Hari Bathini 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 References: <148156671980.4651.13017595439842763683.stgit@hbathini.in.ibm.com> <148156680219.4651.12310355352884515738.stgit@hbathini.in.ibm.com> <878trkajlc.fsf@xmission.com> <4c6c4754-6a87-56bc-3351-fef699cc57e1@linux.vnet.ibm.com> Date: Wed, 14 Dec 2016 08:56:43 +1300 In-Reply-To: <4c6c4754-6a87-56bc-3351-fef699cc57e1@linux.vnet.ibm.com> (Hari Bathini's message of "Wed, 14 Dec 2016 00:37:52 +0530") Message-ID: <87inqnfvr8.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1cGtEm-0005qr-VD;;;mid=<87inqnfvr8.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=101.100.131.98;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18uTMtwLdsVhjAKL/m5mZn72v2HovxIwjw= X-SA-Exim-Connect-IP: 101.100.131.98 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4012] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa08 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa08 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Hari Bathini X-Spam-Relay-Country: X-Spam-Timing: total 1121 ms - load_scoreonly_sql: 0.10 (0.0%), signal_user_changed: 313 (28.0%), b_tie_ro: 311 (27.7%), parse: 3.6 (0.3%), extract_message_metadata: 3.9 (0.3%), get_uri_detail_list: 1.19 (0.1%), tests_pri_-1000: 15 (1.4%), tests_pri_-950: 1.29 (0.1%), tests_pri_-900: 1.06 (0.1%), tests_pri_-400: 36 (3.2%), check_bayes: 34 (3.1%), b_tokenize: 6 (0.6%), b_tok_get_all: 13 (1.2%), b_comp_prob: 2.1 (0.2%), b_tok_touch_all: 6 (0.5%), b_finish: 0.67 (0.1%), tests_pri_0: 702 (62.6%), check_dkim_signature: 0.65 (0.1%), check_dkim_adsp: 211 (18.8%), tests_pri_500: 17 (1.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v3 3/3] perf tool: add cgroup identifier entry in perf report X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1739 Lines: 43 Hari Bathini writes: > 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..? Inode numbers in general are 64bit. The namespace inodes admittedly are currently implemented as 32bit quantities but that is not something we want to hard code into the userspace interface. I would just make the identifier a structure containing the device number and the inode number. It didn't look like perf required the identifier to be a simple integer. Eric