Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp848758pxj; Fri, 11 Jun 2021 13:13:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyFNTnqLVHzgz2iTTUUGz+VmNv0ieBu4uFqoqofx/DFb/wOx2Tdm1jTYZBj2mGxvS9F5bY/ X-Received: by 2002:a50:fe10:: with SMTP id f16mr5474883edt.370.1623442382405; Fri, 11 Jun 2021 13:13:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623442382; cv=none; d=google.com; s=arc-20160816; b=G4unNugA+XaTHDrG4Y8ZewMh7v46UnSDVwgCv1tdW8u3XXwSHfOru2vdhwqm3oTWD3 2HjkltC/qLyao/3eQlKIJ+ehdxzmHJo6y+URmejNPTIZfGcdMdQCLX9Oyz0KyQ127kO5 F8jFy7gPmCpRm1fDdQQlJ1ZD71GXtu/DVmLFylSHq4UntNNssc7kM8ksxdR85dO6tnlq S3/8YbzNQNnNUAkwNz3QzLiBOf0Qenyv3mwO49mHrlFwO6TTXZmQX6pNmPVFMqwNuza5 sGy4o5RjRcbE2FD3IHbf9eqrG7OAjHLgL3GiIlt+zRDuHGRtuE4P8jKdZGKTGc6RJbix j6wg== 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=SGKWZgdLuI4jJ+8UakO+4u1ve/n+sSaYbLfyVIrXiUA=; b=yCcpxUsgVH1M3oJCfiH+CzffQDWyr5EiFjVq2f47FW4aCD0tZ7Z6O1b6eaS3F7NHK/ M3TgxZIK0qTelPuY7j4jV94Ss9ldSnmWHvf61IPxus4xoGYigmxJJmCp9sA8fyNyLeHt rDpoCPIJGop1foSHdTlMwkYNPax8AMIJKc0YQcVyrD/8UVubPnZ9ES3I8FbfjY5fodLb LfdKM1TOfoBx2PehOu2KFEamjrlQtrU2WXBdp/7CTs+EW1wz/JcSNJzysA/lX/CiKr2e Iq1cxMCfkhL546OwisDd0y1V9Bw3zCitgcT/6CH6Wi3+FITagWMuO6xEvwa3AJeHlnRb MErA== 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 r4si5416406edw.55.2021.06.11.13.12.39; Fri, 11 Jun 2021 13:13:02 -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 S230083AbhFKUNc (ORCPT + 99 others); Fri, 11 Jun 2021 16:13:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:58874 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229572AbhFKUNb (ORCPT ); Fri, 11 Jun 2021 16:13:31 -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 68BF3613A9; Fri, 11 Jun 2021 20:03:43 +0000 (UTC) Date: Fri, 11 Jun 2021 16:03:40 -0400 From: Steven Rostedt To: Daniel Bristot de Oliveira Cc: linux-kernel@vger.kernel.org, Phil Auld , Sebastian Andrzej Siewior , Kate Carcia , Jonathan Corbet , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Alexandre Chartre , Clark Willaims , John Kacur , Juri Lelli , linux-doc@vger.kernel.org Subject: Re: [PATCH V3 9/9] tracing: Add timerlat tracer Message-ID: <20210611160340.6970e10c@gandalf.local.home> In-Reply-To: References: <20210607213639.68aad064@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 Fri, 11 Jun 2021 14:59:13 +0200 Daniel Bristot de Oliveira wrote: > ------------------ %< ----------------------------- > It is worth mentioning that the *duration* values reported > by the osnoise: events are *net* values. For example, the > thread_noise does not include the duration of the overhead caused > by the IRQ execution (which indeed accounted for 12736 ns). But > the values reported by the timerlat tracer (timerlat_latency) > are *gross* values. > > The art below illustrates a CPU timeline and how the timerlat tracer > observes it at the top and the osnoise: events at the bottom. Each "-" > in the timelines means 1 us, and the time moves ==>: > > External context irq context thread > clock timer_latency timer_latency > event 18 us 48 us > | ^ ^ > v | | > |------------------| | <-- timerlat irq timeline > |------------------+-----------------------------| <-- timerlat thread timeline > ^ ^ > ===================== CPU timeline ====================================== > [timerlat/ irq] [ dev irq ] > [another thread...^ v..^ v........][timerlat/ thread] > ===================== CPU timeline ====================================== > |-------------| |---------| <-- irq_noise timeline > |--^ v--------| <-- thread_noise timeline > | | | > | | + thread_noise: 10 us > | +-> irq_noise: 9 us > +-> irq_noise: 13 us > > --------------- >% -------------------------------- That's really busy, and honestly, I can't tell what is what. The "context irq timer_latency" is a confusing name. Could we just have that be "timer irq latency"? And "context thread timer_latency" just be "thread latency". Adding too much text to the name actually makes it harder to understand. We want to simplify it, not make people have to think harder to see it. I think we can get rid of the "<-- .* timeline" to the right. I don't think they are necessary. Again, the more you add to the diagram, the busier it looks, and the harder it is to read. Could we switch "[timerlat/ irq]" to just "[timer irq]" and explain how that "context irq timer_latency"/"timer irq latency" is related? Should probably state that the "dev irq" is an unrelated device interrupt that happened. What's with the two CPU timeline lines? Now there I think it would be better to have the arrow text by itself. And finally, not sure if you plan on doing this, but have a output of the trace that would show the above. Thus, here's what I would expect to see: External clock timer irq latency thread latency event 18 us 48 us | ^ ^ v | | |------------------| | |------------------+-----------------------------| ^ ^ ========================================================================= [timerlat/ irq] [ dev irq ] [another thread...^ v..^ v........][timerlat/ thread] <-- CPU task timeline ========================================================================= |-------------| |---------| |--^ v--------| | | | | | + thread_noise: 10 us | +-> irq_noise: 9 us +-> irq_noise: 13 us The "[ dev irq ]" above is an interrupt from some device on the system that causes extra noise to the timerlat task. I think the above may be easier to understand, especially if the trace output that represents it is below. Also, I have to ask, shouldn't the "thread noise" really start at the "External clock event"? -- Steve