Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1450855img; Tue, 19 Mar 2019 07:56:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqx7QTsXYmuJteuHe1FA67j1ySTzwlbdjHokJR83d3QUqk1tiuPR7TlZUpRPnlKsNeqmS6JF X-Received: by 2002:a63:ed11:: with SMTP id d17mr140305pgi.211.1553007411021; Tue, 19 Mar 2019 07:56:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553007411; cv=none; d=google.com; s=arc-20160816; b=FLWfCNeopRYERVjSOylSIfRlYHRLl1gHYj9OWaozag3pRZ8nlVFwTv7lKemQ++dfYc 9yGilfFseIosWWYQVklywUaX3cKMv9Cr2dSGnCyPUNBXx+rjtuposwX6rLGzlukmbWIE 6IPmUXwGUG7D9OzCAO5rC3r90Lwl3RIRALEwUY3Td6WQN/95KWA963jMYYm2yvLk0h4S /6f7VeVyIDaxMtg/qAzhCntmKY0iIxd+lY1LQIdGkjFkE9D1skRUqCzvXYwGoi95VAYl RqqeqkNStn4ZEgj687JwaX1KLSWtcuA7qhII2lw2waclolrEK6n8EAhepJAaENhdhlbC N5BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=ifH/c9+AOZjyrB9+dOWReD6VGCHDAtqDyggFPZbrdQs=; b=NaxfLAaLlNRjBeYdPedESlhAu5eFu7MUP2wLoNzwTvCdwp1ax6UUlSHKvXr16K6+yr Z8mqH4XMinJdkEk/leABtwkJPuSpFBzyPxtDIiP8aL2NxxzcuTRa8W2l6QW2ctkoeFHA XG9v5wd7ZQAfUYZzwpMqE7hNaVYPiwDNO9eIs3+PRum5iaEpnRzYJXVW2mOa/S2l+A7J azSOG3Axb+7yafEYhrRTnnBkFoCNOhZwDdfs/XN2tf4m/y+xvHOIPpCZZtglChq0WN4/ LJzxieucscYWbnON6tNrlT7JReShWyyi8vlPamOsQmFXz06vnZ97YCA/d0kzAxLYF6Am 9WgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b8si11949732plr.54.2019.03.19.07.56.35; Tue, 19 Mar 2019 07:56:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727386AbfCSOz3 (ORCPT + 99 others); Tue, 19 Mar 2019 10:55:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:59990 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726697AbfCSOz1 (ORCPT ); Tue, 19 Mar 2019 10:55:27 -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 A1A85217F9; Tue, 19 Mar 2019 14:55:26 +0000 (UTC) Date: Tue, 19 Mar 2019 10:55:25 -0400 From: Steven Rostedt To: Doug Anderson Cc: Daniel Thompson , Ingo Molnar , Jason Wessel , kgdb-bugreport@lists.sourceforge.net, Brian Norris , LKML Subject: Re: [PATCH v5 2/3] tracing: Add trace_total_entries() / trace_total_entries_cpu() Message-ID: <20190319105525.7686763b@gandalf.local.home> In-Reply-To: References: <20190318204741.116550-1-dianders@chromium.org> <20190318204741.116550-2-dianders@chromium.org> <20190319112537.5yi7gelkk4ixswmu@holly.lan> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 19 Mar 2019 07:45:38 -0700 Doug Anderson wrote: > > > +unsigned long trace_total_entries_cpu(struct trace_array *tr, int cpu) > > > +{ > > > + unsigned long total, entries; > > > + > > > + if (!tr) > > > + tr = &global_trace; > > > > This function is only ever called with tr set to NULL which means tr is > > an argument looking for a user. > > > > I wouldn't mind except if this was following copying prior art to keep > > the API feel the same but I can't find any other trace function where > > the trace_array can be substituted for NULL. AFAICT all the existing > > sites where global_trace is used will use it unconditionally. I'm in the process of making everything work better with tracing instances. Which means, making all the APIs use the tr pointer (which is the descriptor for the instance). All new APIs added to the tracing infrastructure should reference a "tr" pointer, and not use the global_trace directly. We can default it if tr is NULL. There are currently lots of cases in the code that do so, but I'm trying to get rid of them. > > Happy to change this if you guys want. At the moment the > trace_total_entries() comes straight from Steven's suggestion at: > > https://lkml.kernel.org/r/20190315144130.1aa36931@gandalf.local.home > > Ugh, but while looking at this it looks like I totally forgot one > piece of feedback from Steven: to move the disabling of the tracing > out so it's not re-enabled after counting but before dumping. Not > sure how I missed that. :( > > I'll wait to spin until I hear from Steven if he wants me to remove > the "struct trace_array *tr" argument, then I'll post out a v6 with > the fix I forgot... Please keep the tr argument. Thanks! -- Steve