From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19BA7C433FE for ; Fri, 4 Dec 2020 00:08:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A7758207D1 for ; Fri, 4 Dec 2020 00:08:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A7758207D1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6yYSKplQVO+Ubo7GwuEsyeymrWYDnA+LqBHp96TV0Ww=; b=cDGFWCKXXX0JKVY3oU/R+hPas 5QE3GLfxTnLVRM0bU0U0x/FPWiQENkOdvEAuVWXWYuvaGpOOEfkOc2tGiD6AzhbGfkgiBum1FGGvG VsjBaA9unbSQrvrFxB/bT0yX4arIaCPE+rf283nhYND5wpJL/avLqeUS1MUHKzLA5+w/K9M23DvB5 xyD3r+bG1+z6GCbjReHom3mMs9asapNXhyOAdbaCKkRsZ7E6MvREAeitXEYL4hqcUlau5PbGGv1U2 T6VL9JI7PsNhHfx2CkPe4Tcf/VZNguvEDi95J4RmnEgwkTuxuXSn0cP1Fknc2XGK7nb3s+Z3Co9E5 Y/er1TZYg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkycx-00061j-C5; Fri, 04 Dec 2020 00:07:11 +0000 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkycu-00060Z-MY for linux-arm-kernel@lists.infradead.org; Fri, 04 Dec 2020 00:07:10 +0000 Received: by mail-pf1-x436.google.com with SMTP id t8so2446921pfg.8 for ; Thu, 03 Dec 2020 16:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hElgmtc7PJJLc48EH95WqE542tCHlShsoybOtFUxsPM=; b=lZ1RIYdPTNItbLd+7kmC26xGvAXxapbVxIV85XTGaDAwmkHGv59dhrOUF33yNnPU9P LZ08gTv+1Y2UKsDHaTUNJYEuu9/RhEN/z6NnGh8Mezk6ycSIX4znSoQkOJXccOCz7Ovp 0Z47ogkC5n9V5UGHLCHcEj9x21Y4PmW3niD2rzxy7rZfOXcEzz9wrIR5T6+3T/nzJuHq qlkbSEIUE4YedxF0dE0BKkjjyz/NIVsvBKB/uW0QgQVkAEw9WUaDBSOlYw5bEx6xBUnf QlOwAxZpwAvmBhbItk9YeLIiHGyFxbUhA8daBgZX6qpfaPmJNhTJnyButIxM4DHuwqx4 ZRIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hElgmtc7PJJLc48EH95WqE542tCHlShsoybOtFUxsPM=; b=QFRx4D02LyUw0njJDJrXpPheKBHz3tqoZyyzzegZLarYR4b9irnSOqIDEQQ7fs78F1 s/CJ++/13Ymjd9r64GuqZbMvEJlyqN0Jx72cAt0wDEb8fOqTdPmj/xtRmkIfrUSIhffn NAANxW9qhyLp3mlsUhp6fy8/nng4OeRxu6diXyv3fAqGLitb0Mr+uE19daCu+usXkQwR EFhlpPgS9Q6Y5SDeR5JfQ+/ZRl2oWg+Eg7GbuIk+5ZYWNGmUwqo7mSx8GnlyCJ2vNmZN KIk0+n15DJJV76ril5832xyYkjFlgkMm096LYwgPObtKaTelUwRjEsXZpuxU4JC04bSI 9z7w== X-Gm-Message-State: AOAM533gnFYjjsECUS6sS364OcjIRv9KomQ2Sf4ZBthEPMXLahdnOEtO uvj1xn9oLZWJiwRLoffn2Cypcw== X-Google-Smtp-Source: ABdhPJxq4b+0dAEDAWHo5J7YWwonfoA44bfJmj1hGhExnewdvVXSqfrPlp5xT3XC+ZU6WRbehtTbMg== X-Received: by 2002:aa7:9315:0:b029:18b:6372:d43e with SMTP id 21-20020aa793150000b029018b6372d43emr1288827pfj.2.1607040424574; Thu, 03 Dec 2020 16:07:04 -0800 (PST) Received: from xps15 (S0106889e681aac74.cg.shawcable.net. [68.147.0.187]) by smtp.gmail.com with ESMTPSA id s189sm2725013pfb.60.2020.12.03.16.07.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Dec 2020 16:07:03 -0800 (PST) Date: Thu, 3 Dec 2020 17:07:01 -0700 From: Mathieu Poirier To: Leo Yan Subject: Re: [PATCH] drivers/perf: Enable PID_IN_CONTEXTIDR with SPE Message-ID: <20201204000701.GA1403545@xps15> References: <20201130162454.28255-1-james.clark@arm.com> <20201130164650.GA25187@willie-the-truck> <20201201041040.GC28939@leoy-ThinkPad-X240s> <20201201230935.GD28496@willie-the-truck> <20201203063941.GE28939@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201203063941.GE28939@leoy-ThinkPad-X240s> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201203_190708_790933_D04BBC12 X-CRM114-Status: GOOD ( 39.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Al Grant , Suzuki K Poulose , John Garry , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, James Clark , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Dec 03, 2020 at 02:39:41PM +0800, Leo Yan wrote: > Hi Will, > > [ + Mathieu ] > > On Tue, Dec 01, 2020 at 11:09:36PM +0000, Will Deacon wrote: > > On Tue, Dec 01, 2020 at 12:10:40PM +0800, Leo Yan wrote: > > > On Mon, Nov 30, 2020 at 04:46:51PM +0000, Will Deacon wrote: > > > > On Mon, Nov 30, 2020 at 06:24:54PM +0200, James Clark wrote: > > > > > Enable PID_IN_CONTEXTIDR by default when Arm SPE is enabled. > > > > > This flag is required to get PID data in the SPE trace. Without > > > > > it the perf tool will report 0 for PID which isn't very useful, > > > > > especially when doing system wide profiling or profiling > > > > > applications that fork. > > > > > > > > Can perf not figure out the pid some other way? (e.g. by tracing context > > > > switches and correlating that with the SPE data?). > > > > > > For perf 'per-thread' mode, we can use context switch trace event as > > > assisted info to select thread context. But for "system wide" mode and > > > "snapshot" mode in perf tool, since the trace data is continuous, I > > > think we cannot use context switch trace event to correlate the SPE > > > trace data. > > > > Is there no way to correlate them with something like CNTVCT? > > Good point. Yes, we can convert CNTVCT to system time; I read the > code in the perf's intel-pt.c and found the timestamp is used to > correlate the auxtrace heap. I think it's better to dig more for > detailed implementation. > > > > > Also, how does this work with pid namespaces? > > > > > > Here we are studying the implemetation of Intel-PT and Arm CoreSight. > > > > > > The context ID is stored into the hardware trace data when record; > > > afterwards when perf tool decodes the trace data and detects the > > > packet for context ID, it will select the machine's thread context in > > > perf [1]. Since the perf tool gathers all the threads infomation in > > > perf data file, based on the context ID, it can find the corresponding > > > thread pointer with function machine__find_thread() [2]. > > > > > > Since your question is for "pid namespace", to be honest, I don't know > > > how perf tool to handle any confliction for differrent processes share > > > the same PID, and I am not sure if you are asking CGroup related stuff > > > or not. If this cannot answer your question, please let me know. > > > > My point was that the pid value written to CONTEXTIDR is a global pid > > and does not take namespacing into account. If perf is run inside a pid > > namespace, it will therefore not work. Will is correct. That is why coresight doesn't allow contextID tracing if the request is made from inside a PID namespace. But that is only from the sysfs interface. From perf the guard wasn't put in place, probably because CPU wide trace scenarios were not implemented yet. > > Understand now. > > The perf events PERF_RECORD_ITRACE_START/PERF_RECORD_SWITCH/ > PERF_RECORD_SWITCH_CPU_WIDE can be used to set pid/tid in perf. So this > would be a safe way for perf tool running in pid namespace. > Remember that the events you are referring to above are all processed in the perf tools where there is no way to go from pid to vpid. And to preempt any hope, there is no way to "switch" the pid for the vpid in the trace stream. That is all done in hardware. I think the easiest solution is to simply avoid using contextIDs when PID namespaces are involved. > Loop in Mathieu, this is a common issue for both Arm SPE and CoreSight > (IIRC, though CoreSight's timestamp is not strictly attaching to Arm arch > timer counter, the trend is to unify this for using arch timer > counter). > > I think James could continue to upstream a new patch by following your > suggestion for enabling PID_IN_CONTEXTIDR, eventually, it's a feature > for Arm SPE to record CONTEXTIDR in its packet. > > Your questions inspired me, thanks! > > Leo > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel