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.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 C37B8C433ED for ; Thu, 13 May 2021 13:59:41 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 4677F6127A for ; Thu, 13 May 2021 13:59:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4677F6127A 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6g8iN7/vlp7zx/ohTXroNhpeL455CiWIlfT5mW2JFfU=; b=kMHyjthFNUpnk7DnMaWMiANBJ vOlFKymDQqmY3yQvTxF2Q3Les2MbQWbzJDdcpV4nIUPKqDlnxlyX1ELQYIym2gmCvbzwZgMEZxqJs s/WPuy3pnjTIuDt3H+HkGgYRrdEv+rn3OgB6GpBvWINVzaJ8td1cJgm4PiiyhODlh3MGznVZvveqM w5LGWCpUuuPCsw3pTcdwjSFfyj4wK8kQgP1hzziJCXgWjlu5G5ivWBZxnDZvfhH2xulhnS+rn3c/4 roYyfTDzNrp3qh9uwfpX0l5nZ/S7vG09eEdfsMgqPs5JzOC8wvctGsGWMMdtOaTXVbBlZP45rMNN5 QFVF8Oe+Q==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lhBqF-005gcX-7i; Thu, 13 May 2021 13:57:31 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lhBqC-005gcD-QW for linux-arm-kernel@desiato.infradead.org; Thu, 13 May 2021 13:57:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=ExiEjSbBGx8HkFJsq+wn6hB95fxBDc6VAT4MjtX7ykA=; b=R3jLeqhQ0F4NYLEp8AqG+JDq16 zJ9dH3kkAdE51SPSPEsVlQGJWHHGwmapel9HQIoBiFHG9NqDY01v5Biq4H95GRBuJSLQICpmzQbuD Ih5v73420o/ea1V5HuoaldfGd1dlVlR1EbbPmpo+SwT7XOeuEsXvz2SzpmbI4tlqtn3ttGTF+Afns 7/NHl0wzSiKudt/kzNQ0kN6vJeualpop54m/oxAYlXAkLmukqWYsrkS9PP6VvNWctexG0JAABA8DA 3tgaGpbYQ25421yONrZyByU401Xus0cQPgEeSogPvdtLefBQMfsCRWCCq/sAuwxwPZHGHis2dgwg5 GRJcxUAQ==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lhBqA-00BIQ3-02 for linux-arm-kernel@lists.infradead.org; Thu, 13 May 2021 13:57:27 +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 79EB61713; Thu, 13 May 2021 06:57:23 -0700 (PDT) Received: from [10.57.81.122] (unknown [10.57.81.122]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0D0533F73B; Thu, 13 May 2021 06:57:20 -0700 (PDT) Subject: Re: [RFC PATCH] perf cs-etm: Handle valid-but-zero timestamps To: Leo Yan Cc: coresight@lists.linaro.org, mathieu.poirier@linaro.org, al.grant@arm.com, branislav.rankov@arm.com, denik@chromium.org, suzuki.poulose@arm.com, anshuman.khandual@arm.com, Mike Leach , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , John Garry , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210507095814.17933-1-james.clark@arm.com> <3926c523-3fdb-66de-8b9c-b68290a5053e@arm.com> <20210510053904.GB4835@leoy-ThinkPad-X240s> <20210512012002.GB249068@leoy-ThinkPad-X240s> From: James Clark Message-ID: Date: Thu, 13 May 2021 16:57:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210512012002.GB249068@leoy-ThinkPad-X240s> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210513_065726_167627_3AC67AD3 X-CRM114-Status: GOOD ( 29.90 ) 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 12/05/2021 04:20, Leo Yan wrote: > On Tue, May 11, 2021 at 04:53:35PM +0300, James Clark wrote: > > [...] > >> Do you have any idea about what to do in the overflow case? > > A quick thinking is to connect the kernel timestamp and correlate the > overflow case for CoreSight's timestamp, but this approach will cause > complexity. And considering if the overflow occurs for not only once > before the new kernel timestamp is updated, it's hard to handle for > this case. So seems to me, printing warning is a better choice. > >> I think I will submit a >> new patchset that makes the new 'Z' timeless --itrace option work, because that also >> fixes this issue, without having to do the original workaround change in this RFC. > > Good finding for these options for zero timestamps! > >> But I'd also like to fix this overflow because it masks the issue by making non-zero >> timestamps appear even though they aren't valid ones. >> >> I was thinking that printing a warning in the overflow case would work, but then I would >> also print a warning for the zero timestamps, and that would make just a single case, >> rather than two. Unless we just have slightly different warning text? > > Printing two different warnings is okay for me, which is more clear > for users. > >> Something like this? Without the zero timestamp issue, the underflow issue probably wouldn't >> be encountered. But at least there would be some visibility if it did: >> >> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c >> index 059bcec3f651..5d8abccd34ab 100644 >> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c >> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c >> @@ -17,6 +17,7 @@ >> >> #include "cs-etm.h" >> #include "cs-etm-decoder.h" >> +#include "debug.h" >> #include "intlist.h" >> >> /* use raw logging */ >> @@ -294,9 +295,11 @@ cs_etm_decoder__do_soft_timestamp(struct cs_etm_queue *etmq, >> static ocsd_datapath_resp_t >> cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq, >> const ocsd_generic_trace_elem *elem, >> - const uint8_t trace_chan_id) >> + const uint8_t trace_chan_id, >> + const ocsd_trc_index_t indx) > > Do we really need the new argument "indx"? If print "trace_chan_id", > can it give the info that the timestamp is attached to which tracer? I thought that just the channel ID wouldn't be very useful for locating where the issue is when doing --dump-raw-trace. By printing "Idx:..." it can be pasted straight into the search in perf and you'll jump straight to the part where the error happened. If you only have the channel ID then you'd still need to get a debugger out and find out the index if you want to look into the problem. I will include the index in the new patch I will submit now, but I don't insist on keeping it so let me know what you think. James _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel