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 6CEEFC433ED for ; Tue, 11 May 2021 12:41:53 +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 B6D6C6121E for ; Tue, 11 May 2021 12:41:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6D6C6121E 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=Bw5EDrx+pKNdsEVNcCfFflTSRIu7l8b8mAI0BBwEwBA=; b=BirJ5GssJxgrCuGG6Hu6nkW+V Zw7QyBG3scmALrNUddAMihkA4cXSQqLHcx1HgGmhoPPpFy9LAELfNE96lC+aYL06kK+ZzB1XMAGfJ GfisUSNwZtEYrBNROP9thbOiS1nNNlyabY2Bqxx/QVj0tyCm7PZ5eGg7auieOWqtORh7xzvfFnK77 C7xFOii/J8OZclxyBexXl78vDQX5FR0SlFfF0//sNEk2+0BdNfSiq5IBp97XBMdjh4fr99k7o1l/S wQ58UC9xu23Tfiepm0CXhRwRY/7mgwDnYIYfGrZsv5cehnchfgnen+NHAPVucbGGO5T0ZqAtsmdIc 75aKASl/g==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lgRg6-00HQxn-BG; Tue, 11 May 2021 12:39:58 +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 1lgPBf-00Gnxn-EQ for linux-arm-kernel@desiato.infradead.org; Tue, 11 May 2021 10:00:23 +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=v8y6jqx0VxGYguPCq5fQyX5YPditv7GnxJW5fbP8fr8=; b=kiJp+eqeSw8Ea0Mktaumwbtzsi wHxEsy4ib2KvcX4ShluNst3xtQ7RfnpyTtkBBFnxgpPxBSh1yufDGYHvettBxuvHx9ZKZqMikgpjn j9jioM6yF/EtVqBLwPVg+hEOji4g5E1T4D8QpWnnPxQRD2TSTPq3V5LIGvVv3WPs7snfmpwEVm5Wy Fhi/dTcq6Q/Bd92BQsN0TBKR8GpJJ33KvBvVr/a4cjkKGklOb0pyikKySaKNSdVSKVZm5OqVGZV1C uMWqk1fAXj2MByvNNXmHIJKcmxHqHiIshI4DRybd1V1PoDJYsfh7cLBGdvtELP+FQIJjNjyh/FgUO yOSu/DMg==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lgPBc-009SAp-HE for linux-arm-kernel@lists.infradead.org; Tue, 11 May 2021 10:00:22 +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 5C02F169C; Tue, 11 May 2021 03:00:19 -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 5DC2C3F719; Tue, 11 May 2021 03:00:16 -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> <20210511080504.GC8273@leoy-ThinkPad-X240s> From: James Clark Message-ID: <35fbbead-167a-51d5-f781-a7b9890857b2@arm.com> Date: Tue, 11 May 2021 13:00:14 +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: <20210511080504.GC8273@leoy-ThinkPad-X240s> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210511_030020_702654_62B0B292 X-CRM114-Status: GOOD ( 20.61 ) 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 11/05/2021 11:05, Leo Yan wrote: > On Mon, May 10, 2021 at 01:39:04PM +0800, Leo Yan wrote: >> On Fri, May 07, 2021 at 01:02:35PM +0300, James Clark wrote: >>> >>> >>> On 07/05/2021 12:58, James Clark wrote: >>>> There is an intermittent issue on Trogdor devices that >>>> results in all Coresight timestamps having a value of zero. >>> >>> I've attached a file here that has the issue. From the dump you >>> can see the zero timestamps: >>> >>> Idx:69; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0 >>> Idx:71; ID:10; I_ATOM_F1 : Atom format 1.; E >>> Idx:72; ID:10; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFFE723C65824 ~[0x5824] >>> >>> This doesn't have an impact on decoding as they end up being >>> decoded in file order as in with timeless mode. >> >> Just remind, as Mike has mentioned that if the timestamp is zero, it >> means the hardware setting for timestamp is not enabled properly. So >> for system wide or per CPU mode tracing, it's better to double check >> what's the reason the timestamp is not enabled properly. >> >> IIUC, this patch breaks the existed rational in the code. Let's think >> about there have 4 CPUs, every CPU has its own AUX trace buffer, and >> when decode the trace data, it will use 4 queues to track the packets >> and every queue has its timestamp. >> >> CPU0: cs_etm_queue -> ... -> packet_queue->timestamp >> CPU1: cs_etm_queue -> ... -> packet_queue->timestamp >> CPU2: cs_etm_queue -> ... -> packet_queue->timestamp >> CPU3: cs_etm_queue -> ... -> packet_queue->timestamp >> >> The issue is if all CPUs' timestamp are zero, it's impossible to find >> a way to synthesize samples in the right time order. > > I saw Denis's replying for the hardware issue for timestamp, wander if > can add a new option "--force-aux-ts-zero" to override the hardware > timestamp issue. Without the option "--force-aux-ts-zero", the > developers still have chance to observe the failure case caused by the > abnormal timestamps. > Hi Leo, Now that you mention arguments, I remembered that you already can force something like that with --disable-order. There is also a recent commit "perf intel-pt: Support Z itrace option for timeless decoding" which introduces this option: @@ -869,6 +869,7 @@ The letters are: L synthesize last branch entries on existing event records s skip initial number of events q quicker (less detailed) decoding + Z prefer to ignore timestamps (so-called "timeless" decoding) I will investigate if these are more relevant to fix this issue. Thanks James > Thanks, > Leo > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel