From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965785AbcKJTuk (ORCPT ); Thu, 10 Nov 2016 14:50:40 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:44832 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965739AbcKJTuj (ORCPT ); Thu, 10 Nov 2016 14:50:39 -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: <147877784354.29988.8570048236764105701.stgit@hbathini.in.ibm.com> Date: Thu, 10 Nov 2016 13:48:10 -0600 In-Reply-To: <147877784354.29988.8570048236764105701.stgit@hbathini.in.ibm.com> (Hari Bathini's message of "Thu, 10 Nov 2016 17:07:54 +0530") Message-ID: <87a8d7m805.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=1c4vMo-0007ug-Sf;;;mid=<87a8d7m805.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=75.170.125.99;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19Oon/ztQCtjwYro1qkeOT362TVwemvk14= X-SA-Exim-Connect-IP: 75.170.125.99 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 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.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Hari Bathini X-Spam-Relay-Country: X-Spam-Timing: total 1324 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.4 (0.3%), b_tie_ro: 2.3 (0.2%), parse: 0.79 (0.1%), extract_message_metadata: 3.0 (0.2%), get_uri_detail_list: 1.42 (0.1%), tests_pri_-1000: 3.7 (0.3%), tests_pri_-950: 1.19 (0.1%), tests_pri_-900: 1.06 (0.1%), tests_pri_-400: 26 (2.0%), check_bayes: 25 (1.9%), b_tokenize: 6 (0.5%), b_tok_get_all: 10 (0.8%), b_comp_prob: 2.1 (0.2%), b_tok_touch_all: 3.2 (0.2%), b_finish: 0.64 (0.0%), tests_pri_0: 1271 (96.0%), check_dkim_signature: 0.46 (0.0%), check_dkim_adsp: 2.6 (0.2%), tests_pri_500: 5 (0.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/3] perf: add support for analyzing events for containers 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 in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hari Bathini writes: > 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 inode number is 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 is nothing but the cgroup namespace's > inode number. This approach is based on the suggestion from Peter > Zijlstra here: https://patchwork.kernel.org/patch/9305655/ Where is the check that ensures that only the someone with capable(CAP_SYS_ADMIN) can use this interface. This interface is not namespace clean in multiple dimensions so it can not be used generally? You are not allowed to move struct mount_namespace into include/linux/mnt_namespace.h. Al Viro will crucify you with cause. Those are implementation details the rest of the kernel should not be digging into. Where are the device numbers that go with those inode numbers you are exporting? For now all of those inodes live on the filesystem but I am not giving guarantees to userspace that do not work for ordinary filesystems. Eric