Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1417928pxb; Wed, 6 Apr 2022 18:21:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCEPzJeGu3zHyHKLshx4zgdlEODJgYb9GNeceqzOsRQETF+KRRoZ3+ijB1re67ib43havg X-Received: by 2002:a17:906:d41:b0:6ce:78b0:8113 with SMTP id r1-20020a1709060d4100b006ce78b08113mr11054851ejh.357.1649294511852; Wed, 06 Apr 2022 18:21:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649294511; cv=none; d=google.com; s=arc-20160816; b=Uj73eItyKOijab3ZrHqCsJ78JvkKm3jgnTOUpFbVV27i4c+tHJWmvndKp+RmvqKiLP FybGJ6kNxdcxknrE53IbVQDmDc1EZAQ4SQMaDEJ0ChjLcAgz8mK861BxhjqkJJ4Ur99+ Sa87PGCDsyjyiIlRT44dpkgwWO3GWLN6UliYbJnbQIzfDmHBMKitspPpgkmO4NFHGhAb Oh40IGji8SpnCdhfNdUEMdPC82V8VcwX62muflKmf1QzdUlKQqTQufzhXhmCzDJHRmB7 4kGUySctMlaARcW/SJJRKSZpFJpPAAu98cpAfNkkg5mp14cmEtQ+92tuE5vnDOVUaSVV QULg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=t/OlsO1FKFR5EhHV9ORO6nOTkIXhtzmPjFoAc9FJDKQ=; b=aokyjcxFP645Nk+9A1kn6u9QJBIl9QhfzvZpZCNjpT8kWoyy2WDLMSjr8tADy0fPBk lA6CnAbuJtTGyFhpFaJKNW/CBdRQFhKIG8NSEsdjk6TOlzdzOyMYwSDWbu1dEfkQ5N3c OZ/Z+/g+0eKpW3qW32m8fk7QacZWlPHIsSFE3vDk598gVF6ehKmqVpxxhWnYkii0375H OdsTvumRB9lVEs0zde4MiIdNhvwojXG/WVcYRE6JFXR1qTIp5XlklGswptm9ZqGxy6yT UwfU9Ub/BroZcia7zfYLhALrdbOLhGdJHUL4sFmg/AkmKYp5Wg1hugc0Txu1SNDLxUbm +jvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XDKGV13O; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p14-20020a50d88e000000b0041c80bbd0cdsi10736492edj.371.2022.04.06.18.21.27; Wed, 06 Apr 2022 18:21:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XDKGV13O; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235117AbiDFVFk (ORCPT + 99 others); Wed, 6 Apr 2022 17:05:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48462 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234834AbiDFVFU (ORCPT ); Wed, 6 Apr 2022 17:05:20 -0400 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88687B368F for ; Wed, 6 Apr 2022 12:38:21 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id d29so4706340wra.10 for ; Wed, 06 Apr 2022 12:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t/OlsO1FKFR5EhHV9ORO6nOTkIXhtzmPjFoAc9FJDKQ=; b=XDKGV13OWuTcpHQtxWsO2pGZJRHijPeLw1lbRH7aQAqCra/Xto8IkoJy+FHPQBBqzl n7QL7p9otGPG7HD1r3iEHoLODppCk6NYvyPIrrXGEJzDuN/b4mQJh7ucRV5HEKUG9oNX LmU02pkmW3bRXIPADpVyIH8lyA8xNakFXmcSU0MVt6juSgKk2GIOOT3Wv7hM7jFXTwcp MoGyktVuWPHTg1idcweYHQ6PYAy6d2mkF6g51Gfcpq7VazIXyEQHME2oWBciEYPZCqIu YbUBiKzmhK6MF3zbUl0Iwf3vNgRGf90MPFj/K20OhRwOHesuZ2sAUeoYEcc7MasYFimx rcGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t/OlsO1FKFR5EhHV9ORO6nOTkIXhtzmPjFoAc9FJDKQ=; b=QlgdUsGjsjCve9WczL24J4wxhNz0U/SYrz9wNbWhzdRQ17Hs8tLSR0hphwCngvWikq RW08fINNFvOs3nyIulxpOFfDkGhqSvLiRwmo44/h8ED9vopCopyC+TngOq8kWLDQZ7K+ mY/h2NI52a36XOfoiwA5QbRJt/DYsckYW9FxIYSZS2yZypKxO8WDFaIzvX80qy8zItOc jr3xP9/3Vo50G62YaXNvAzbvLwimMzlX/ZnZbSqvRyzD2jkN7b//vttRM4Z3TGNsMSZN kIKA8bbhboFv2ViSqq9Z07Ji4Fs30gM8vpgK4obVgmlijZWQaGwL8NK4i1uFBSFyXZ7p RTkA== X-Gm-Message-State: AOAM5303q43B8aT/uM4c/AWCnswn+UodWNn9CXfRZvp3PN5z60APkP1X 1f4LDkiAzy/5GKUCfPhS2MIu40f9kNkGFOROSzqefA== X-Received: by 2002:a05:6000:16cd:b0:207:81ed:b733 with SMTP id h13-20020a05600016cd00b0020781edb733mr2507341wrf.111.1649273900001; Wed, 06 Apr 2022 12:38:20 -0700 (PDT) MIME-Version: 1.0 References: <20220308205000.27646-1-mike.leach@linaro.org> <20220308205000.27646-7-mike.leach@linaro.org> <20220406171132.GA16110@p14s> In-Reply-To: <20220406171132.GA16110@p14s> From: Mike Leach Date: Wed, 6 Apr 2022 20:38:08 +0100 Message-ID: Subject: Re: [PATCH 06/10] coresight: perf: traceid: Add perf notifiers for trace ID To: Mathieu Poirier Cc: suzuki.poulose@arm.com, coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, linux-perf-users@vger.kernel.org, leo.yan@linaro.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mathieu, On Wed, 6 Apr 2022 at 18:11, Mathieu Poirier wrote: > > On Tue, Mar 08, 2022 at 08:49:56PM +0000, Mike Leach wrote: > > Adds in notifier calls to the trace ID allocator that perf > > events are starting and stopping. > > > > This ensures that Trace IDs associated with CPUs remain the same > > throughout the perf session, and are only release when all perf > > sessions are complete. > > > > Signed-off-by: Mike Leach > > --- > > drivers/hwtracing/coresight/coresight-etm-perf.c | 16 +++++++++++++++- > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c > > index c039b6ae206f..008f9dac429d 100644 > > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c > > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c > > @@ -22,6 +22,7 @@ > > #include "coresight-etm-perf.h" > > #include "coresight-priv.h" > > #include "coresight-syscfg.h" > > +#include "coresight-trace-id.h" > > > > static struct pmu etm_pmu; > > static bool etm_perf_up; > > @@ -223,11 +224,21 @@ static void free_event_data(struct work_struct *work) > > struct list_head **ppath; > > > > ppath = etm_event_cpu_path_ptr(event_data, cpu); > > - if (!(IS_ERR_OR_NULL(*ppath))) > > + if (!(IS_ERR_OR_NULL(*ppath))) { > > coresight_release_path(*ppath); > > + /* > > + * perf may have read a trace id for a cpu, but never actually > > + * executed code on that cpu - which means the trace id would > > + * not release on disable. Re-release here to be sure. > > + */ > > + coresight_trace_id_put_cpu_id(cpu, coresight_get_trace_id_map()); > > A CPU gets a traceID in event_etm_start() when the event is installed for > running. Do you see a scenario where etm_free_aux() is called without > previously calling event_etm_stop()? > To ensure that IDs are obtained in a timely manner, they assign on read. Therefore when cs_etm.c::cs_etm_info_fill() is called, potentially the ID will be read for all CPUs - and dumped into the AUXINFO data at the top of the perf.data file. However, a --per-thread execution may actually only start the event on a subset of cpus, hence we ensure that all cpus are released. This was proven during testing when I ran both --per-thread and cpu wide tests with logging monitoring the ID assignments. I have programmed this deliberately defensively - on the basis that the timings and orderings of the code/callbacks in todays perf may not necessarily be the same in tomorrows. perf. In future we may be able to use Suzuki's idea of embedding the ID into an alternative packet in the perf.data file. but I think that should be a separate change as it affects decode in a big way. Regards Mike > > + } > > *ppath = NULL; > > } > > > > + /* mark perf event as done for trace id allocator */ > > + coresight_trace_id_perf_stop(); > > + > > free_percpu(event_data->path); > > kfree(event_data); > > } > > @@ -314,6 +325,9 @@ static void *etm_setup_aux(struct perf_event *event, void **pages, > > sink = user_sink = coresight_get_sink_by_id(id); > > } > > > > + /* tell the trace ID allocator that a perf event is starting up */ > > + coresight_trace_id_perf_start(); > > + > > /* check if user wants a coresight configuration selected */ > > cfg_hash = (u32)((event->attr.config2 & GENMASK_ULL(63, 32)) >> 32); > > if (cfg_hash) { > > -- > > 2.17.1 > > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK