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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9E9D3C71153 for ; Mon, 4 Sep 2023 15:24:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Cc:From:References:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EhfzugdNvupiCsdiEDL8TtanjXjKKZOAAW3JrP2VQOs=; b=IIf2jgXcPKVjSu 3CzV/g8MIGHhcqDg9C4lfPfqLyfuEnqpwIE0iO0EUdp0ib4LwZGxJwjNebYEpOL4B6MZJXuMVmp2Z KyoEj3zu1qhy+PlBqB1wRMnr9OoB78NALUb/rwfQnhg9Gr+OqucLvDG8NnIlGVNoEKo2676PJKBxi 0GsiN69MxL9h7Ahvn02lZr1jo0en753L4TwRzH6N68KqwE/uOfsdPLYcxBTcZ8mF5qRq/y5ybSCq2 gxCRwCjJ94AcGO931SWFuhkwrhemtUQdWqp6Arj7eVlxWON3y4YJJ4Aroug+O3aAh0rYeyHyOAnOg 4JJxfPpjGfJDvqFrfLHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qdBQc-004N4O-1l; Mon, 04 Sep 2023 15:23:50 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qdBQZ-004N3T-2j for linux-arm-kernel@lists.infradead.org; Mon, 04 Sep 2023 15:23:49 +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 A6F25143D; Mon, 4 Sep 2023 08:24:22 -0700 (PDT) Received: from [192.168.1.3] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 85D903F738; Mon, 4 Sep 2023 08:23:42 -0700 (PDT) Message-ID: <8eb9b2c0-1dbb-8a93-fc4e-463a6daadb9c@arm.com> Date: Mon, 4 Sep 2023 16:23:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v1 1/2] perf cs-etm: Validate timestamp tracing in per-thread mode Content-Language: en-US To: Leo Yan References: <20230827133557.112494-1-leo.yan@linaro.org> <20230827133557.112494-2-leo.yan@linaro.org> From: James Clark Cc: Arnaldo Carvalho de Melo , Suzuki K Poulose , Mike Leach , John Garry , Will Deacon , Mark Rutland , Peter Zijlstra , Ingo Molnar , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20230827133557.112494-2-leo.yan@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230904_082347_932548_5E07AACB X-CRM114-Status: GOOD ( 27.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 27/08/2023 14:35, Leo Yan wrote: > So far, it's impossible to validate timestamp trace in Arm CoreSight when > the perf is in the per-thread mode. E.g. for the command: > > perf record -e cs_etm/timestamp/ --per-thread -- ls > > The command enables config 'timestamp' for 'cs_etm' event in the > per-thread mode. In this case, the function cs_etm_validate_config() > directly bails out and skips validation. > > Given profiled process can be scheduled on any CPUs in the per-thread > mode, this patch validates timestamp tracing for all CPUs when detect > the CPU map is empty. There is an edge case where the profiled process is known by the user to be pinned to a specific CPU, rather than possibly running on all CPUs, so this isn't always true. But I think that can be worked around by changing it to a per-cpu session to get around the new error. Given that this validation was only supposed to be best effort information and not get in the way you could say to not make it more restrictive. But it's quite a small edge case so either way: Reviewed-by: James Clark > > Signed-off-by: Leo Yan > --- > tools/perf/arch/arm/util/cs-etm.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c > index b8d6a953fd74..cf9ef9ba800b 100644 > --- a/tools/perf/arch/arm/util/cs-etm.c > +++ b/tools/perf/arch/arm/util/cs-etm.c > @@ -205,8 +205,17 @@ static int cs_etm_validate_config(struct auxtrace_record *itr, > for (i = 0; i < cpu__max_cpu().cpu; i++) { > struct perf_cpu cpu = { .cpu = i, }; > > - if (!perf_cpu_map__has(event_cpus, cpu) || > - !perf_cpu_map__has(online_cpus, cpu)) > + /* > + * In per-cpu case, do the validation for CPUs to work with. > + * In per-thread case, the CPU map is empty. Since the traced > + * program can run on any CPUs in this case, thus don't skip > + * validation. > + */ > + if (!perf_cpu_map__empty(event_cpus) && > + !perf_cpu_map__has(event_cpus, cpu)) > + continue; > + > + if (!perf_cpu_map__has(online_cpus, cpu)) > continue; > > err = cs_etm_validate_context_id(itr, evsel, i); _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel