Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2817816pxb; Tue, 21 Sep 2021 08:18:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxYFa/hXy5MJfpHOPx9E4dTdassKceRqjEQ+3a9L9BrC3Gc8OaRBmDRaMDyDlwTUt1gTVHJ X-Received: by 2002:a02:5b0a:: with SMTP id g10mr466278jab.112.1632237507963; Tue, 21 Sep 2021 08:18:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632237507; cv=none; d=google.com; s=arc-20160816; b=RorHbzulL0kOYbMRmYQJwrfmvYd/5FiJhZHw3nnCI7ET1r1YzxoebCTMVgavFzv6pf T0Lf/mvnaAdS6BjV721kz5eykIvMbQqJAU0D5GejQ1mLITi+0GtVIk5+60Sn04sHE+9w 9b55xyOwsWV414Yc8oLTzIqFjgaYreiiUEQTrXYA+NP0p8PF/GdhxepA6+lGtLn1fSEL mn7+OXRRY71IMwosvCKjOVutWLuLLTn2D7XpSo3UvJZhSgsaWhBJT7iLaLfpJ2VbJ9WY poRbJDntyoP87runf4LSZxBL991HjToVF3GTZ+FOh82Oa8yCzfTb0ZJoY3uN8jejoymo 1dPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=aXP49dUwOr4wFV77A1ODYn77RlAJY5JxxIiiVfkrBUk=; b=jwNSSQgsT+otALv4uMOIt7uHpULqzqY/Hdma6c1TkXcLKAeW0fKYgMZ3LvY9yeXYXy J2rQf4JMvQuNd+0NjITNg4wpzo2WXYVOEp1gcFH5bDkbOxe7lxnX5S8pJ3Zvkoon+FA6 C9Cp0nJnMs1LMvp+iy1SztUCxTOyP2gJr5vARsLPmtDbYiK12yBDZfhkqiGrvac/IFCe Bf2FnT1k/s9tUqKOFYGh9AQltT7pj6euEn0I7JFphtdQLTr9A8T+GFiCIYN+VTa7pD4X R1xS8pz9Yt5JZbMcjHjnJnNbh5pp/Eu4JKSILrGotMpgrZk0/piSySuwVb4IpcSVKYRL cRbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gjzLdJnT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l4si14851434jaf.96.2021.09.21.08.18.15; Tue, 21 Sep 2021 08:18:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gjzLdJnT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S233946AbhIUPSz (ORCPT + 99 others); Tue, 21 Sep 2021 11:18:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233932AbhIUPSy (ORCPT ); Tue, 21 Sep 2021 11:18:54 -0400 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 896B5C061574 for ; Tue, 21 Sep 2021 08:17:26 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id t4so13630831plo.0 for ; Tue, 21 Sep 2021 08:17:26 -0700 (PDT) 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=aXP49dUwOr4wFV77A1ODYn77RlAJY5JxxIiiVfkrBUk=; b=gjzLdJnT5P9WLtW0MYPb/jAJ5Ct9/IjeS5rsfWjlML+N0YenRVQ/wZXJn9sp6q37gj Lq4gT1uhIBTVGhoxVH27m96br5Rfr5BLCp/821HMZr6ysxSBYtRcHjc0BdCgKp3qd3Yk qorTV4N45MA2owHVCRjQEjDrroLmwYR9TtSq67+Js9ZhVI94zfXkkIpmVPbv5ImMjSJT k/IW2V/s0JSLj26cFn9aOLmGL3e2kaQ3qLh9pICQxKQbPqiKPb7Bq20AWhsU1Nus8aUf 5vUVGbl0RvEBuv/WyWzrxG347EiPS0JB392shMwhFA87YqChFkyzr1XMGMo90fr3GdX0 bfWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aXP49dUwOr4wFV77A1ODYn77RlAJY5JxxIiiVfkrBUk=; b=KKgw+0qm8aN+zVit1rV73h/mMF1VvmGa1ZLCRbrixuAd6mVZY78idp1ynqNq3/sNzS y8dvYp7PhYKZM/5X5VsvPbjfJBnTcRogeW5pobiN9v4UFdvxLJfuq2MvIbY921Kb564D L+FpW/uq4rAdP4Ou/cDWDjotPys+BzRb/cD7i3B2xz002Q9ZELQt8+rPsWvcpNyKu8/S eV26sizy00Age1Sjag59209nMbIAernIdwvIcncOIxvDB5oWRWbm7W5fz3rgJlyVzwYC 6PYapv0o0HpXE5cNixQj/NSQU/GoFZxoqIPPB4K5YOSENy7PS8cdDXGC0n9QdO1Inp7b +kPw== X-Gm-Message-State: AOAM531DYxRs4wfSsbagLCDOBH9pfTY0FFVbIcGiRFSfq6/dbUQGu4Bu wXyzdNmVlcJI2jqf7lumeBeh3g== X-Received: by 2002:a17:90a:428f:: with SMTP id p15mr5953127pjg.75.1632237445962; Tue, 21 Sep 2021 08:17:25 -0700 (PDT) Received: from p14s (S0106889e681aac74.cg.shawcable.net. [68.147.0.187]) by smtp.gmail.com with ESMTPSA id j25sm17323352pff.34.2021.09.21.08.17.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Sep 2021 08:17:23 -0700 (PDT) Date: Tue, 21 Sep 2021 09:17:21 -0600 From: Mathieu Poirier To: James Clark Cc: suzuki.poulose@arm.com, coresight@lists.linaro.org, Mike Leach , Leo Yan , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] coresight: Don't immediately close events that are run on invalid CPU/sink combos Message-ID: <20210921151721.GA2059841@p14s> References: <20210921130231.386095-1-james.clark@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210921130231.386095-1-james.clark@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 21, 2021 at 02:02:31PM +0100, James Clark wrote: > When a traced process runs on a CPU that can't reach the selected sink, > the event will be stopped with PERF_HES_STOPPED. This means that even if > the process migrates to a valid CPU, tracing will not resume. > > This can be reproduced (on N1SDP) by using taskset to start the process > on CPU 0, and then switching it to CPU 2 (ETF 1 is only reachable from > CPU 2): > > taskset --cpu-list 0 ./perf record -e cs_etm/@tmc_etf1/ --per-thread -- taskset --cpu-list 2 ls > > This produces a single 0 length AUX record, and then no more trace: > > 0x3c8 [0x30]: PERF_RECORD_AUX offset: 0 size: 0 flags: 0x1 [T] > > After the fix, the same command produces normal AUX records. The perf > self test "89: Check Arm CoreSight trace data recording and synthesized > samples" no longer fails intermittently. This was because the taskset in > the test is after the fork, so there is a period where the task is > scheduled on a random CPU rather than forced to a valid one. > > Specifically selecting an invalid CPU will still result in a failure to > open the event because it will never produce trace: > > ./perf record -C 2 -e cs_etm/@tmc_etf0/ > failed to mmap with 12 (Cannot allocate memory) > > The only scenario that has changed is if the CPU mask has a valid CPU > sink combo in it. > > Testing > ======= > > * Coresight self test passes consistently: > ./perf test Coresight > > * CPU wide mode still produces trace: > ./perf record -e cs_etm// -a > > * Invalid -C options still fail to open: > ./perf record -C 2,3 -e cs_etm/@tmc_etf0/ > failed to mmap with 12 (Cannot allocate memory) > > * Migrating a task to a valid sink/CPU now produces trace: > taskset --cpu-list 0 ./perf record -e cs_etm/@tmc_etf1/ --per-thread -- taskset --cpu-list 2 ls > > * If the task remains on an invalid CPU, no trace is emitted: > taskset --cpu-list 0 ./perf record -e cs_etm/@tmc_etf1/ --per-thread -- ls > > Signed-off-by: James Clark > --- > .../hwtracing/coresight/coresight-etm-perf.c | 27 +++++++++++++++---- > 1 file changed, 22 insertions(+), 5 deletions(-) Very interesting corner case - and I like your solution. Arnaldo, please consider. Reviewed-by: Mathieu Poirier > > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c > index 8ebd728d3a80..79346f0f0e0b 100644 > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c > @@ -452,9 +452,14 @@ static void etm_event_start(struct perf_event *event, int flags) > * sink from this ETM. We can't do much in this case if > * the sink was specified or hinted to the driver. For > * now, simply don't record anything on this ETM. > + * > + * As such we pretend that everything is fine, and let > + * it continue without actually tracing. The event could > + * continue tracing when it moves to a CPU where it is > + * reachable to a sink. > */ > if (!cpumask_test_cpu(cpu, &event_data->mask)) > - goto fail_end_stop; > + goto out; > > path = etm_event_cpu_path(event_data, cpu); > /* We need a sink, no need to continue without one */ > @@ -466,16 +471,15 @@ static void etm_event_start(struct perf_event *event, int flags) > if (coresight_enable_path(path, CS_MODE_PERF, handle)) > goto fail_end_stop; > > - /* Tell the perf core the event is alive */ > - event->hw.state = 0; > - > /* Finally enable the tracer */ > if (source_ops(csdev)->enable(csdev, event, CS_MODE_PERF)) > goto fail_disable_path; > > +out: > + /* Tell the perf core the event is alive */ > + event->hw.state = 0; > /* Save the event_data for this ETM */ > ctxt->event_data = event_data; > -out: > return; > > fail_disable_path: > @@ -517,6 +521,19 @@ static void etm_event_stop(struct perf_event *event, int mode) > if (WARN_ON(!event_data)) > return; > > + /* > + * Check if this ETM was allowed to trace, as decided at > + * etm_setup_aux(). If it wasn't allowed to trace, then > + * nothing needs to be torn down other than outputting a > + * zero sized record. > + */ > + if (handle->event && (mode & PERF_EF_UPDATE) && > + !cpumask_test_cpu(cpu, &event_data->mask)) { > + event->hw.state = PERF_HES_STOPPED; > + perf_aux_output_end(handle, 0); > + return; > + } > + > if (!csdev) > return; > > -- > 2.28.0 >