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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 F28C8C43462 for ; Tue, 11 May 2021 08:26:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C7BBB6147E for ; Tue, 11 May 2021 08:26:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230484AbhEKI1x (ORCPT ); Tue, 11 May 2021 04:27:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230333AbhEKI1q (ORCPT ); Tue, 11 May 2021 04:27:46 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3C7FC06175F for ; Tue, 11 May 2021 01:26:38 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id 10so15672425pfl.1 for ; Tue, 11 May 2021 01:26:38 -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=fa+2ltcDEPwkPDfIHcTKZuy0/HUg90dSSL9do71Mi80=; b=qhIGNjiOHObdA23pa8t/oqmzE8bVqoQoWvcqps09WqR73y+oOgWlAcNyEK41xTfC9C YTc85TrPUe6gYBX0v10iAKU7LTSmBCG4Fv74z2tG7FB+Z4B59uDG9Dj+6dV+yK8u9EmK YFel7KdLFa01mmTkMqlaPjIjsciJWvmabyI361CWJ5vqSZ/acyNfpOJkBvfXN5wmsgdw EP2yQlvGwntXD0gk2Tg4pJFbWqSMbkETpBEk7KSwX6AchU8iwPhwB/owzblGBCSou8qJ kZYCEuR9pm4hH4tvoMYNC9En0TEb3+4BZhv2+w08BVelF7wnnF0ceI9TPbq/398fl2BQ +eQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=fa+2ltcDEPwkPDfIHcTKZuy0/HUg90dSSL9do71Mi80=; b=CzxZqSNe6dQKWn/hZZmWsJoHMm7jip/pwT2ZnkEMacyVVJ9evgPTbjYlQt4hbUKlkJ lxuQcZgQPdqq9Jrvg5BnPCiWxra0qEH0J8bNFxKJ3B3KizkkjwG7puToFCTeOxTcNcrg ZxOwK9fiZyTHv3nb47m3F/CDvCWB8fMnhtb+rlq5Lzl134XMUNlXKbOE7N5Vx1UtL6j6 pucSoLXU4+iWq6/Q6RFdqCPMyyjLLlhCFjpYZNuSukWHaLES1eX089u0e1tuDZGllEPl xxrLDl/BTs1dAnlq60qOW4O3o8SpH29XCLBfTJaYQ4VL3v6iWkcFgNEs0Oz4f5x3IuVQ DVVQ== X-Gm-Message-State: AOAM532Nu5ZH0eDMqfw+HZQ92ll8/7QXF0XKH5BT1eTlKXAqRlDnCD86 i/UAq6oRUCS+96pQJQX2/44ipg== X-Google-Smtp-Source: ABdhPJz0e1glZlykLvQX+TD/ZmOHUdRyDZNDiJVoUoXdKA6dEhMaARNsyyBs+2ac7mb7OmNyBv3F6A== X-Received: by 2002:a65:550e:: with SMTP id f14mr1593762pgr.160.1620721598262; Tue, 11 May 2021 01:26:38 -0700 (PDT) Received: from leoy-ThinkPad-X240s (ec2-18-166-63-222.ap-east-1.compute.amazonaws.com. [18.166.63.222]) by smtp.gmail.com with ESMTPSA id js6sm1714615pjb.0.2021.05.11.01.26.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 May 2021 01:26:37 -0700 (PDT) Date: Tue, 11 May 2021 16:26:31 +0800 From: Leo Yan To: Denis Nikitin Cc: James Clark , coresight@lists.linaro.org, Mathieu Poirier , Al Grant , Branislav Rankov , Denis Nikitin , Suzuki Poulose , 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 Subject: Re: [RFC PATCH] perf cs-etm: Handle valid-but-zero timestamps Message-ID: <20210511082631.GD8273@leoy-ThinkPad-X240s> References: <20210507095814.17933-1-james.clark@arm.com> <3926c523-3fdb-66de-8b9c-b68290a5053e@arm.com> <20210510053904.GB4835@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Denis, On Tue, May 11, 2021 at 01:06:03AM -0700, Denis Nikitin wrote: > Hi Leo, > > > 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. > > The bug is confirmed by HW verification. Yeah. > > 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. > > Is it really impossible or it just can lead to incorrect decoding? Thanks for correcting. Just clarifying: with this change, perf can decode and synthesize samples, but the sequence of samples is not time-based ordering. > I verified the profiles generated with zero timestamps and this patch > on Trogdor (8 CPU cores) and I don't see any significant difference > in the quality of the AutoFDO profiles. > > If mixed packets don't cause errors in reconstructing the branches > but instead mess up with their timeline then it probably won't matter > for AutoFDO which just collects statistics of the branches. > What do you think? Understand. CoreSight trace data can be used for two purposes: tracing and profiling. For AutoFDO profiling, it's okay for with zero timestamps based on your conclusion; on the other hand, the change can introduce confusion if any user wants to use CoreSight for tracing and review the program flow (like use "perf script") command. The change in this patch is valid for me, but it's better to connect with a new option (like "--force-aux-ts-zero" mentioned in my another replying), this can allow users to explictly to force AUX trace timestamp as zero (or in other word, users can use this option to ignore AUX timestamp if the timestamp is not reliable). Thanks, Leo 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=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 AE285C433B4 for ; Tue, 11 May 2021 12:14:51 +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 0A85B61480 for ; Tue, 11 May 2021 12:14:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A85B61480 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=G1KjUyIwNJQR+0Oi31TM7Ji7RVz+iYjZeZndKCk2lVA=; b=MhU1M+EhhDfrdyHK2CUaeByGn PNRJSUAG5J4uq72Jqvh84uIxiBoSs3lumV+zqjWmVPy+3MBZyM0qvo+KeVf8liyZ9vgYBK6fJoiQf 5CKya0m+E5tKX7fMMENThGAQX1A6T2Ow/MB+VRAKfY2/twFkPAZLYapsxP61XZE8YKSh/+GFThbd2 KSdBoY8RVgXbNXPO1W8NK7gDkWCoiwRKB8IvnUD80QyJRjHUAX+JSvtWUlYXm6X4c8Hl9sY/AkOhZ aOEhqKsgBQGwH1PUIfSYYlL3zKpg/Sx8RCJ7kx7HGRIJsV6Z+xESYh4mrAXSaXMV5Yt2n9Z/WvFT1 GnlzLdi4Q==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lgRGb-00HJr2-0c; Tue, 11 May 2021 12:13:37 +0000 Received: from [2607:7c80:54:e::133] (helo=bombadil.infradead.org) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lgNiz-00Gb5w-U4 for linux-arm-kernel@desiato.infradead.org; Tue, 11 May 2021 08:26:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=fa+2ltcDEPwkPDfIHcTKZuy0/HUg90dSSL9do71Mi80=; b=3VswrjZwVKtqyMm6GSZAj5aOQT 0iZ6RP23JNTaoe4E3WdTN4Rq7+OXxrBOTLfkazMPnE51+SpIhfPZ2VJJsjK4IRlIcZu9m//+U0I5o whsdcg0u2gJIsttjTMv7dsJqi0+gNsedXBQ/vJzHhkUJbuLiNKzeG7lJCSnJz7amVoL4Qqmn5h7jI nYtC+nf6EJv2nKaWnQj0lvSOypZw1i1fnypYPVFBJHdzniNE2tsxt9aVhknxbSqyBYUg1QQYzb0+c R6dRJDqdLd5/Kd3sdadFdO5H2HXchyeOfWLcqbatYc8XMJfy9FkcIPXUC8pL+klMgdCsiFjAOnvj0 1Vr3havQ==; Received: from mail-pf1-x431.google.com ([2607:f8b0:4864:20::431]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lgNix-009OQs-3i for linux-arm-kernel@lists.infradead.org; Tue, 11 May 2021 08:26:40 +0000 Received: by mail-pf1-x431.google.com with SMTP id q2so15477585pfh.13 for ; Tue, 11 May 2021 01:26:38 -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=fa+2ltcDEPwkPDfIHcTKZuy0/HUg90dSSL9do71Mi80=; b=qhIGNjiOHObdA23pa8t/oqmzE8bVqoQoWvcqps09WqR73y+oOgWlAcNyEK41xTfC9C YTc85TrPUe6gYBX0v10iAKU7LTSmBCG4Fv74z2tG7FB+Z4B59uDG9Dj+6dV+yK8u9EmK YFel7KdLFa01mmTkMqlaPjIjsciJWvmabyI361CWJ5vqSZ/acyNfpOJkBvfXN5wmsgdw EP2yQlvGwntXD0gk2Tg4pJFbWqSMbkETpBEk7KSwX6AchU8iwPhwB/owzblGBCSou8qJ kZYCEuR9pm4hH4tvoMYNC9En0TEb3+4BZhv2+w08BVelF7wnnF0ceI9TPbq/398fl2BQ +eQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=fa+2ltcDEPwkPDfIHcTKZuy0/HUg90dSSL9do71Mi80=; b=kLupWNVRQgK1JLncolS+nCmFxMLaqbaKCX//HFbtsJiY5CF19qMVEt5ApPqByxO9Pc ldnfonqFD8Q665GYMe4n76a7ai772fvcbpNrcbOgOeaN3aoU3is1a0XSJhjKCuQIIYU0 r/rcOr4ZPp/F9aQYCb1DzZUe/dfqhrlTz0uAiFuoBt71wmheL0VRiyXytLp0HLCCa6/i 6KQBgLzkIXiLSmtCSVS76BZrojJUG0KONMW5cgnJEfzizIMxIVnZv0BTTu9uw4guftfx 2GoNouJWY+9ityUS4johAPegXjKyaEXV75umd5CWnH91rMtfxC9jDYIYZ9U/Pz3V2CyU cXzw== X-Gm-Message-State: AOAM532FBr+N13erUHsWmxkNRSAa9bw0PL+D9vAgTfxOqQY/Ery7gvke NGCV5pa0Qv//CaJIbfplIf8l7Q== X-Google-Smtp-Source: ABdhPJz0e1glZlykLvQX+TD/ZmOHUdRyDZNDiJVoUoXdKA6dEhMaARNsyyBs+2ac7mb7OmNyBv3F6A== X-Received: by 2002:a65:550e:: with SMTP id f14mr1593762pgr.160.1620721598262; Tue, 11 May 2021 01:26:38 -0700 (PDT) Received: from leoy-ThinkPad-X240s (ec2-18-166-63-222.ap-east-1.compute.amazonaws.com. [18.166.63.222]) by smtp.gmail.com with ESMTPSA id js6sm1714615pjb.0.2021.05.11.01.26.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 May 2021 01:26:37 -0700 (PDT) Date: Tue, 11 May 2021 16:26:31 +0800 From: Leo Yan To: Denis Nikitin Cc: James Clark , coresight@lists.linaro.org, Mathieu Poirier , Al Grant , Branislav Rankov , Denis Nikitin , Suzuki Poulose , 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 Subject: Re: [RFC PATCH] perf cs-etm: Handle valid-but-zero timestamps Message-ID: <20210511082631.GD8273@leoy-ThinkPad-X240s> References: <20210507095814.17933-1-james.clark@arm.com> <3926c523-3fdb-66de-8b9c-b68290a5053e@arm.com> <20210510053904.GB4835@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210511_012639_206049_23F1111B X-CRM114-Status: GOOD ( 24.65 ) /bin/ln: failed to access 'reaver_cache/texts/20210511_012639_206049_23F1111B': No such file or directory X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210511_012639_206049_23F1111B X-CRM114-Status: GOOD ( 20.79 ) 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 Hi Denis, On Tue, May 11, 2021 at 01:06:03AM -0700, Denis Nikitin wrote: > Hi Leo, > > > 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. > > The bug is confirmed by HW verification. Yeah. > > 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. > > Is it really impossible or it just can lead to incorrect decoding? Thanks for correcting. Just clarifying: with this change, perf can decode and synthesize samples, but the sequence of samples is not time-based ordering. > I verified the profiles generated with zero timestamps and this patch > on Trogdor (8 CPU cores) and I don't see any significant difference > in the quality of the AutoFDO profiles. > > If mixed packets don't cause errors in reconstructing the branches > but instead mess up with their timeline then it probably won't matter > for AutoFDO which just collects statistics of the branches. > What do you think? Understand. CoreSight trace data can be used for two purposes: tracing and profiling. For AutoFDO profiling, it's okay for with zero timestamps based on your conclusion; on the other hand, the change can introduce confusion if any user wants to use CoreSight for tracing and review the program flow (like use "perf script") command. The change in this patch is valid for me, but it's better to connect with a new option (like "--force-aux-ts-zero" mentioned in my another replying), this can allow users to explictly to force AUX trace timestamp as zero (or in other word, users can use this option to ignore AUX timestamp if the timestamp is not reliable). Thanks, Leo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel