Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp159222pxb; Fri, 9 Apr 2021 22:03:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjv1kon4IDmIMy4a72pBxMj14NRYyCs+mXwUCWpEsgJzEsYIgvPYrokyHyab78l/qFShPK X-Received: by 2002:a17:90a:7f95:: with SMTP id m21mr16548637pjl.174.1618031007842; Fri, 09 Apr 2021 22:03:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618031007; cv=none; d=google.com; s=arc-20160816; b=krLlqxCzN6v9BItPmlmqBwdAStq1qeSYz7IZXX/UpvQXCZOEAgeGRBbRXbZrIJMv0/ jUnN51Gf/1dlCYOLH7HCBO8gW39cX7p5b0z7o/VOvjW0WCykgJuNmj9jH9stkR+lrP+B gUF9xrgAphAW+g6gs+4iNCIPSE63XL3OiTad2weRGYiidDRbrsSsx8RLYLugKaZuRIoa yKZw4Es5Fw3ziQPUcWTxR/r41MDF4/T2ND2VrarTbxOT0V2ULiXAv+T+wQ3asY028nEw jWebXpNuKWznFMkrg5OajjUG/PMNXSSql88qnx1famX3bppzP4K/Q+dtCqta8ai7DJmF LRuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Oe35wE+BbVYSlAv6bLKQWBrNW+CpBkb1nP7qyvMaXOo=; b=RpvmXkGO1QKJDWx+p/534oC1GKtP4EjtErhDIkVWpuDuBA5sFK6oug6y+7wQW77ElT qH3+nrhR+g2LE1SZJezCgyWBsGgl5ASsk5imhcNoBFes+k7WiHt6Q/jWgHkCj8b7+kwX O6BsZCIbfAtxWGdRq29Cg/qzsmHfbDT4CoJsx4bhl77EaKTpxzEF2v2lIxjADNdIE55Q pMSMbCj/pilz/MWCXr1ecBuj0oQ9XzI/o5OOxlj9dPn88jyOeRzCGkMU9k9B4eXEauah 2fCqzvCJQTjPBZTwTElGS6/M9yz5nU0w34By5lHvHPS+J3S+0ZWamiYA0GN82ptNWpbl 87Pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=dakQ+7hD; 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 n4si6044441pgb.118.2021.04.09.22.03.16; Fri, 09 Apr 2021 22:03: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=dakQ+7hD; 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 S234219AbhDJFC1 (ORCPT + 99 others); Sat, 10 Apr 2021 01:02:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234236AbhDJFC0 (ORCPT ); Sat, 10 Apr 2021 01:02:26 -0400 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DC56C061762 for ; Fri, 9 Apr 2021 22:02:11 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id f29so5383513pgm.8 for ; Fri, 09 Apr 2021 22:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Oe35wE+BbVYSlAv6bLKQWBrNW+CpBkb1nP7qyvMaXOo=; b=dakQ+7hDI1n5d61cGeZvMd84eX85QsLx2hO+uFeKBPnbmiVnsshDUV+1ujTxrB+ObS 27ata5OTwKYpGKcNnkH7DDnZHEgUZXdMbeRoIkllbxeK2e2a5iRNksB/dchRn+fzZHIZ 90FwUQJghrprLe3oqW/j0/+ORgd1031GGlouMIAZfmlaU7jUhCRDvq17abgU2UgZ8ziw CkWnCuY9l9tWfd2bU3lq7n2Td08gtCtxr3IDdTrdtYrV0WbODywdgtR9MOq8thijUJGs RnzWkJoN7Rml8Nf+TxcdGOXnoU54aqq8aWGwptPjHqD+b4uWPiHMPrA8rGkyqMRLhmvg +jhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Oe35wE+BbVYSlAv6bLKQWBrNW+CpBkb1nP7qyvMaXOo=; b=kZLZErRH57U85Ov/3N2gkkpjT+syKvj6ZjvtVmkGdqNk0j6UonmdCc1wvQohk2Na1s C3KeMJG/t4D8NnVYU6AdrmzwkFzuo28cvkEX0f5O/B5wUyTKK7dSfIrEQkbTbih+YUPU zwRIAUQN8931QUXTiixc2Zivn99C0peU1sUn0sLFAQpA2I8L8pFDYFdKi24drYW7tNcF tuzFWz2EZRXVqZbwnafbq3AQ1RSg38XaZRu1vnB4VDiX66hK2pUwtxvcXyFZ6vpo14sn ntCGBVkUMcZkVTswmnRaJX0w1nckkIgIAXtrglvsA3pkb3Q5vagsih2GrseqYCo7Ws5S XPsw== X-Gm-Message-State: AOAM531wK9kyXwoXYWLpK5n+MnPCrgkypH/FgjPHydPrcI6c4jOdPt4X TTRDnep0tp0C/udmGsChZbp0iw== X-Received: by 2002:a62:1757:0:b029:23e:9917:7496 with SMTP id 84-20020a6217570000b029023e99177496mr15395996pfx.51.1618030930814; Fri, 09 Apr 2021 22:02:10 -0700 (PDT) Received: from localhost ([116.206.101.232]) by smtp.gmail.com with ESMTPSA id w18sm3575933pjh.19.2021.04.09.22.02.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Apr 2021 22:02:10 -0700 (PDT) From: Leo Yan To: Arnaldo Carvalho de Melo , Al Grant , John Garry , Will Deacon , Mathieu Poirier , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Adrian Hunter , Dave Martin , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, James Clark Cc: Leo Yan Subject: [PATCH v3 5/6] perf arm-spe: Bail out if the trace is later than perf event Date: Sat, 10 Apr 2021 13:00:45 +0800 Message-Id: <20210410050046.5394-6-leo.yan@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210410050046.5394-1-leo.yan@linaro.org> References: <20210410050046.5394-1-leo.yan@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It's possible that record in Arm SPE trace is later than perf event and vice versa. This asks to correlate the perf events and Arm SPE synthesized events to be processed in the manner of correct timing. To achieve the time ordering, this patch reverses the flow, it firstly calls arm_spe_sample() and then calls arm_spe_decode(). By comparing the timestamp value and detect the perf event is coming earlier than Arm SPE trace data, it bails out from the decoding loop, the last record is pushed into auxtrace stack and is deferred to generate sample. To track the timestamp, everytime it updates timestamp for the latest record. Signed-off-by: Leo Yan --- tools/perf/util/arm-spe.c | 37 ++++++++++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c index ec7df83b50fd..8facda81a06c 100644 --- a/tools/perf/util/arm-spe.c +++ b/tools/perf/util/arm-spe.c @@ -434,12 +434,36 @@ static int arm_spe_sample(struct arm_spe_queue *speq) static int arm_spe_run_decoder(struct arm_spe_queue *speq, u64 *timestamp) { struct arm_spe *spe = speq->spe; + struct arm_spe_record *record; int ret; if (!spe->kernel_start) spe->kernel_start = machine__kernel_start(spe->machine); while (1) { + /* + * The usual logic is firstly to decode the packets, and then + * based the record to synthesize sample; but here the flow is + * reversed: it calls arm_spe_sample() for synthesizing samples + * prior to arm_spe_decode(). + * + * Two reasons for this code logic: + * 1. Firstly, when setup queue in arm_spe__setup_queue(), it + * has decoded trace data and generated a record, but the record + * is left to generate sample until run to here, so it's correct + * to synthesize sample for the left record. + * 2. After decoding trace data, it needs to compare the record + * timestamp with the coming perf event, if the record timestamp + * is later than the perf event, it needs bail out and pushs the + * record into auxtrace heap, thus the record can be deferred to + * synthesize sample until run to here at the next time; so this + * can correlate samples between Arm SPE trace data and other + * perf events with correct time ordering. + */ + ret = arm_spe_sample(speq); + if (ret) + return ret; + ret = arm_spe_decode(speq->decoder); if (!ret) { pr_debug("No data or all data has been processed.\n"); @@ -453,10 +477,17 @@ static int arm_spe_run_decoder(struct arm_spe_queue *speq, u64 *timestamp) if (ret < 0) continue; - ret = arm_spe_sample(speq); - if (ret) - return ret; + record = &speq->decoder->record; + /* Update timestamp for the last record */ + if (record->timestamp > speq->timestamp) + speq->timestamp = record->timestamp; + + /* + * If the timestamp of the queue is later than timestamp of the + * coming perf event, bail out so can allow the perf event to + * be processed ahead. + */ if (!spe->timeless_decoding && speq->timestamp >= *timestamp) { *timestamp = speq->timestamp; return 0; -- 2.25.1