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=-11.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_GIT autolearn=unavailable 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 C5FCBC433E0 for ; Fri, 22 Jan 2021 15:22:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9593C23A9A for ; Fri, 22 Jan 2021 15:22:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728805AbhAVPWD (ORCPT ); Fri, 22 Jan 2021 10:22:03 -0500 Received: from foss.arm.com ([217.140.110.172]:52824 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728818AbhAVPTn (ORCPT ); Fri, 22 Jan 2021 10:19:43 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1753811D4; Fri, 22 Jan 2021 07:18:41 -0800 (PST) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 2DE803F66E; Fri, 22 Jan 2021 07:18:39 -0800 (PST) From: Suzuki K Poulose To: Peter Zijlstra Cc: Alexander Shishkin , linux-kernel@vger.kernel.org, coresight@lists.linaro.org, Ingo Molnar , will@kernel.org, mark.rutland@arm.com, mike.leach@linaro.org, al.grant@arm.com, anshuman.khandual@arm.com, mathieu.poirier@linaro.org, linux-arm-kernel@lists.infradead.org, jolsa@redhat.com, acme@kernel.org, Suzuki K Poulose Subject: [RFC PATCH 0/1] perf: Handle multiple formatted AUX records Date: Fri, 22 Jan 2021 15:18:28 +0000 Message-Id: <20210122151829.2890484-1-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.24.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an RFC patch to explore the solution to a problem we have in the CoreSight ETM/ETE PMU. CoreSight ETM trace allows instruction level tracing of Arm CPUs. The ETM generates the CPU excecution trace and pumps it into CoreSight AMBA Trace Bus and is collected by a different CoreSight component (traditionally CoreSight TMC-ETR /ETB/ETF), called "sink". Important to note that there is no guarantee that every CPU has a dedicated sink. Thus multiple ETMs could pump the trace data into the same "sink" and thus they apply additional formatting of the trace data for the user to decode it properly and attribute the trace data to the corresponding ETM. However, with the introduction of Arm Trace buffer Extensions (TRBE), we now have a dedicated per-CPU architected sink for collecting the trace. Since the TRBE is always per-CPU, it doesn't apply any formatting of the trace. The support for this driver is under review [1]. Now a system could have a per-cpu TRBE and one or more shared TMC-ETRs on the system. A user could choose a "specific" sink for a perf session (e.g, a TMC-ETR) or the driver could automatically select the nearest sink for a given ETM. It is possible that some ETMs could end up using TMC-ETR (e.g, if the TRBE is not usable on the CPU) while the others using TRBE in a single perf session. Thus we now have "formatted" trace collected from TMC-ETR and "unformatted" trace collected from TRBE. However, we don't get into a situation where a single event could end up using TMC-ETR & TRBE. i.e, any AUX buffer is guaranteed to be either RAW or FORMATTED, but not a mix of both. As for perf decoding, we need to know the type of the data in the individual AUX buffers, so that it can set up the "OpenCSD" (library for decoding CoreSight trace) decoder instance appropriately. Thus the perf.data file must conatin the hints for the tool to decode the data correctly. Since this is a runtime variable, and perf tool doesn't have a control on what sink gets used (in case of automatic sink selection), we need this information made available from the PMU driver for each AUX record. This patch is an attempt to solve the problem by, adding an AUX flag for each AUX record to indicate the type of the trace in them. It can be defined as a PMU specific flag, which each PMU could interpret in its on way (e.g, PERF_AUX_FLAG_PMU_FLAG_1 or could be a dedicated flag for the CoreSight in a "generic" form PERF_AUX_FLAG_ALT_FMT (Thanks Mike Leach for the name). We are looking for suggestions on how best to solve this problem and happy to explore other options if there is a preferred way of solving this. [1] https://lkml.kernel.org/r/1610511498-4058-1-git-send-email-anshuman.khandual@arm.com Suzuki K Poulose (1): perf: Handle multiple formatted AUX records drivers/hwtracing/coresight/coresight-etm-perf.c | 2 ++ include/linux/coresight.h | 1 + include/uapi/linux/perf_event.h | 1 + 3 files changed, 4 insertions(+) -- 2.24.1 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=-11.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham 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 9874AC433DB for ; Fri, 22 Jan 2021 15:20:28 +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 5B4C4235DD for ; Fri, 22 Jan 2021 15:20:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5B4C4235DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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:MIME-Version:Message-Id:Date:Subject:To:From: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=92k4EeNemNBRq5CLoV33JE/Wdf0gJqVBr5q5nOET9lk=; b=epC4OFQR3VYxp3D3ZFr+5JemIu Xunb5FKMqCh9nTg/OWFsVn+Lu9xXErsmRUZH/saaBGcksAsf09pJ0dWhbDlXZ3ytcBuM6U5Wwupfb BGY70wS13RtLdOhQ+mAH02MOg/Rshb1leFdtn+J/qFgNmBa2ltMgle6byfPS45CD2U4UchTtz4w0a XVb1op+PiK4MsxiQ8eOK3HydN5ZLLARODhMucNhLavFwxic5FCaKk/GQ8gqaGXRxJkBfgaK7vXXbj WUqTyfZMyBT9cAkwYLqpx1Cnvoppu5X2YUxWLRraEgvuiQX3BJ13wUOZwCSkRxKTDimIzS+i5Dss5 v57QPC0g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2yD2-000865-6P; Fri, 22 Jan 2021 15:18:48 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2yCx-00084c-FP for linux-arm-kernel@lists.infradead.org; Fri, 22 Jan 2021 15:18:44 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1753811D4; Fri, 22 Jan 2021 07:18:41 -0800 (PST) Received: from ewhatever.cambridge.arm.com (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 2DE803F66E; Fri, 22 Jan 2021 07:18:39 -0800 (PST) From: Suzuki K Poulose To: Peter Zijlstra Subject: [RFC PATCH 0/1] perf: Handle multiple formatted AUX records Date: Fri, 22 Jan 2021 15:18:28 +0000 Message-Id: <20210122151829.2890484-1-suzuki.poulose@arm.com> X-Mailer: git-send-email 2.24.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210122_101843_621028_3A8661D3 X-CRM114-Status: GOOD ( 17.61 ) 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@arm.com, al.grant@arm.com, mathieu.poirier@linaro.org, anshuman.khandual@arm.com, Alexander Shishkin , jolsa@redhat.com, coresight@lists.linaro.org, Suzuki K Poulose , linux-kernel@vger.kernel.org, acme@kernel.org, Ingo Molnar , will@kernel.org, linux-arm-kernel@lists.infradead.org, mike.leach@linaro.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 This is an RFC patch to explore the solution to a problem we have in the CoreSight ETM/ETE PMU. CoreSight ETM trace allows instruction level tracing of Arm CPUs. The ETM generates the CPU excecution trace and pumps it into CoreSight AMBA Trace Bus and is collected by a different CoreSight component (traditionally CoreSight TMC-ETR /ETB/ETF), called "sink". Important to note that there is no guarantee that every CPU has a dedicated sink. Thus multiple ETMs could pump the trace data into the same "sink" and thus they apply additional formatting of the trace data for the user to decode it properly and attribute the trace data to the corresponding ETM. However, with the introduction of Arm Trace buffer Extensions (TRBE), we now have a dedicated per-CPU architected sink for collecting the trace. Since the TRBE is always per-CPU, it doesn't apply any formatting of the trace. The support for this driver is under review [1]. Now a system could have a per-cpu TRBE and one or more shared TMC-ETRs on the system. A user could choose a "specific" sink for a perf session (e.g, a TMC-ETR) or the driver could automatically select the nearest sink for a given ETM. It is possible that some ETMs could end up using TMC-ETR (e.g, if the TRBE is not usable on the CPU) while the others using TRBE in a single perf session. Thus we now have "formatted" trace collected from TMC-ETR and "unformatted" trace collected from TRBE. However, we don't get into a situation where a single event could end up using TMC-ETR & TRBE. i.e, any AUX buffer is guaranteed to be either RAW or FORMATTED, but not a mix of both. As for perf decoding, we need to know the type of the data in the individual AUX buffers, so that it can set up the "OpenCSD" (library for decoding CoreSight trace) decoder instance appropriately. Thus the perf.data file must conatin the hints for the tool to decode the data correctly. Since this is a runtime variable, and perf tool doesn't have a control on what sink gets used (in case of automatic sink selection), we need this information made available from the PMU driver for each AUX record. This patch is an attempt to solve the problem by, adding an AUX flag for each AUX record to indicate the type of the trace in them. It can be defined as a PMU specific flag, which each PMU could interpret in its on way (e.g, PERF_AUX_FLAG_PMU_FLAG_1 or could be a dedicated flag for the CoreSight in a "generic" form PERF_AUX_FLAG_ALT_FMT (Thanks Mike Leach for the name). We are looking for suggestions on how best to solve this problem and happy to explore other options if there is a preferred way of solving this. [1] https://lkml.kernel.org/r/1610511498-4058-1-git-send-email-anshuman.khandual@arm.com Suzuki K Poulose (1): perf: Handle multiple formatted AUX records drivers/hwtracing/coresight/coresight-etm-perf.c | 2 ++ include/linux/coresight.h | 1 + include/uapi/linux/perf_event.h | 1 + 3 files changed, 4 insertions(+) -- 2.24.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel