Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3370504pxj; Tue, 11 May 2021 03:01:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy65/b/Jz/PLKV8mbRWjflMSehW6OPY1dCZZd/EIy77iaDHQP3TX7SuSHD8HkYxawGlvKBU X-Received: by 2002:a05:6e02:1a4b:: with SMTP id u11mr25547761ilv.258.1620727286024; Tue, 11 May 2021 03:01:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620727286; cv=none; d=google.com; s=arc-20160816; b=GcRQk7nTpEY4YuKMFCinesLI8Zr+UAvxTrZfNWVXOn0h0ChkVW2obZvnZBV/2zgQj/ iH0rHUErFqyhLy47Yl0ZXgutMBgIkUDYeMD4sXruFYzLXONth80o7SSmlAwkQatrJS3u k9FL5NUCu7R368xF0U5eAnEe/oqym/SuFsw58N0DnOpRXh+VSSWioTnLQxRVxYCL6Hmd pnr/qbe1vxkDJ4isypP5hN+E1lsXNpx8WLi1EbzZtNaa+lfP5cfdd2y5I3F+xa0FWOVv SGAPm42QkksTTta6YMl0FCEnvZ3Ma+nB//wL4CtoEQj562sf8kquUBdmct2cnNRc2mqm Ql1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=v8y6jqx0VxGYguPCq5fQyX5YPditv7GnxJW5fbP8fr8=; b=sTBo9hkO+aHH6CZpGTZ2q25+FzfXpo2sWGTwfYYyROTG3HhHS7NMD61FHPy4suKMIy 9nL36I7du2aiwLdrctVROuiJFTnnRzKEo9NEWsB3ZFku7zo2Iw0iSuEMtL7x5f63+Zfl pmkRkAMMDaWTDSDkd7XsQ5tc0Xt8nJe6bN/SAT7WnViuM7Ptu8qkTbjGwChaLdLyiDaf khy6KwoywAL6Nu5cly046kz4ELKI9tK31PRTmBmh4Dpmm4YUm3anBZmDsMk9RMjVFgtG JkAWcqw+dt6DQZWoDhQRbwu5gGZAksXZC9QaMLtQymhztpO8CuHvhu8eKh2xxp76pY7L cG7Q== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a2si19503275ilm.87.2021.05.11.03.01.13; Tue, 11 May 2021 03:01:26 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231319AbhEKKB2 (ORCPT + 99 others); Tue, 11 May 2021 06:01:28 -0400 Received: from foss.arm.com ([217.140.110.172]:44258 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229935AbhEKKBZ (ORCPT ); Tue, 11 May 2021 06:01:25 -0400 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-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 >