From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757473AbdACL2Y (ORCPT ); Tue, 3 Jan 2017 06:28:24 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59234 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755836AbdACL2S (ORCPT ); Tue, 3 Jan 2017 06:28:18 -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> 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: Tue, 3 Jan 2017 16:57:54 +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: <20161229014138.GB2341@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: 17010311-0004-0000-0000-0000051452D4 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17010311-0005-0000-0000-000012D232B5 Message-Id: <40b222dc-5149-4f82-4d5e-6a8d188a6a35@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-03_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-1701030187 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Krister, Thanks for reviewing.. 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? > namespace destruction are handled by separate subsystems. It's possible > to have a cgroup notifier run prior to network namespace teardown > occurring. > If it were me, I'd re-use existing convention to identify the namespaces > you want to monitor. The code in nsenter(1) can take a namespace that's > been bind mount'd on a file, or extract the ns information from a task > in /procfs. As PERF_RECORD_NAMESPACES gets all namespaces info, I assume your reservation is with how perf report (patch 3/3) is processed, which could be improved to consider other namespaces as well, once PERF_RECORD_NAMESPACES is in. > My biggest concern is how the sample data is handled after it has been > collected. Both namespaces and cgroups don't survive reboots. Will the > records will contain all the persistent state needed to run a report or > script command at a later date? Yes. Sideband events are emitted when a new thread is created or an existing thread's namespaces are changed, which can be post processed for reporting. > Does this code attempt to enter alternate namespaces in order to record > stack/symbol information for a '-g' style trace? If so, how are you > holding on to that information? There's no guarantee that a particular > container will be alive or have its filesystems reachable from the host > if the trace data is evaluated at a later time. I am not altering the existing behavior of -g option with these patches.. Thanks Hari