Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp3319690pxb; Wed, 14 Apr 2021 02:39:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy1bwrANQMpZYBkQXCNjIZHI1MCftaNJmeq3Fd3zszph6G9UMHTDCmGI8IQ9hOySA8cldCv X-Received: by 2002:a17:906:f155:: with SMTP id gw21mr22231773ejb.170.1618393188842; Wed, 14 Apr 2021 02:39:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618393188; cv=none; d=google.com; s=arc-20160816; b=cR1ibkz0zxsjQ8TfZCh23oKpJ9ZqPJWIAedYlFb2C3wIXWzn2p1B0nEUM06kHYDYlh Ly57V2fkvkm3sFo7/hxbDI4/vh+XcWk4AwkhdMXi++VBOypkqnD4FCV0D3y7QjkFtXvR h1JzhkRVOLrX8xQzAhTXz/iyRg7Pe1ZsEmmrB+abZc20NaIS3/gXcYvEbv/GXSB3WHra rWUdvtSgGGUJlOedQZzKWhBKSayRULYfdOcksaUPA2zQh6DItPuqj/L4Ok5y8fhriJf3 e3pPfoPzmmW+iwlHqMtQBOuxhqnR+LsIdTgOvBU46no1/0xYMRTt+RsQIgCFiYRu9D6i J9Vw== 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:subject:cc:to:from:date; bh=GjMGke/BGUsfE60IDyqrcM4QzC03w3ffboCkQRTb3xM=; b=pJtbjfKq5PCqk4F38m3uKZ4XXg/0aszt/skYGbR+GCL3tBaiNDCQoN6wXIVKDjIF+E kKjJ+Q5CqkSlq5ePIizyMk/ppfJAwv9Wf+EwPWTPNIrMgjwKjppEH2XPDHvwZvKXfJLB mZn+6mIKsaA1h3EuP2nibMVNl3Scygy3z31qABVqctI3VDRz4Xudt3Uk5xxFxMpO9xzg d5+5HacCRFk+HZSGSc85o8rMp5uQLHjhkf0qYY1z47OywZd1bBtbl9oKBLBEUAr5h6qJ i9yVUozIvD2pBn02D3XnET+abGEaxOdYANfY/W3gO+KThKcSxoRxJO/u7Ml0AeuToHMw 2iSg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b16si12920859ejj.404.2021.04.14.02.39.25; Wed, 14 Apr 2021 02:39:48 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348879AbhDNAeW (ORCPT + 99 others); Tue, 13 Apr 2021 20:34:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:59266 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348878AbhDNAeV (ORCPT ); Tue, 13 Apr 2021 20:34:21 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 07F7461249; Wed, 14 Apr 2021 00:34:00 +0000 (UTC) Date: Tue, 13 Apr 2021 20:33:59 -0400 From: Steven Rostedt To: "Yordan Karadzhov (VMware)" Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org Subject: Re: [PATCH v3 1/5] tracing: Define new ftrace event "func_repeats" Message-ID: <20210413203359.322b902e@gandalf.local.home> In-Reply-To: <20210413151736.36ec77eb@gandalf.local.home> References: <20210409181031.26772-1-y.karadz@gmail.com> <20210409181031.26772-2-y.karadz@gmail.com> <20210413151736.36ec77eb@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Apr 2021 15:17:36 -0400 Steven Rostedt wrote: > Running this with trace-cmd record, this displays: > > -0 [001] 261.848848: function: next_zone > -0 [001] 261.848849: func_repeats: next_zone <-need_update (repeats:3 delta_ts: -189) > > Which is confusing in a number of ways. > > 1. It would be better to have it be the actual timestamp of the last repeat. > But that can be done in a trace-cmd plugin (like the function trace has). > > 2. It should be "delta_ns:" because it is not -189 from the timestamp, as > the above time stamp is truncated to microseconds and this is not > obvious to the user. After playing with this some more, I take back #2. As we don't know what units the time stamp is actually in. As it is best to simply show the time stamp of the last event where it matches the other time stamps (which we can do, as I demonstrated in other emails), I think the best answer is to leave the default ambiguous as simply "delta:". That way if it's not processed, all you see is "delta: -189" and if people don't know what that means, they'll either ignore it, or look up its meaning. I think both "delta_ts" and "delta_ns" can be misleading if what is displayed does not match the raw time stamps. -- Steve