Received: by 10.223.164.202 with SMTP id h10csp4854661wrb; Wed, 29 Nov 2017 13:03:25 -0800 (PST) X-Google-Smtp-Source: AGs4zMbsZ9QbrAPwVk0cLlGbU24ZHYD8NzvY5ktQW7AC/8WNK9Mk06KcoD0MVkzci5aJRtFZ6wtD X-Received: by 10.99.49.81 with SMTP id x78mr191931pgx.35.1511989405564; Wed, 29 Nov 2017 13:03:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511989405; cv=none; d=google.com; s=arc-20160816; b=vsghFuPa+D0XTz3tyORJI/r4foIBgRXJdv2+LgTmDz3+UovtSjAR8COnJvF4nuWo1p 2+SapqtwdwNKog/OAUtdci8SfhoBNUUSWzM05YTZ9j702tIrZsuzountRJbG7p2CVBOn oyO+FmOdPFfEBNr9euMxa420wwC/xlcFMYOUjXRrbwmTAeAvyeXfjvspKdiI0vcLYw4Z u4QqriugIqp6mcn8ZwctUKel+LMlRa3AcmXG4lozivaldMLXSSx7x/nII82YTOSq3QFQ WtmwZn3CtOS1A8FDsWNEG4lbnDll2N+UkidnjbDGG7eKfcqLdfGYL8w1n0JK0A4LCO6K 029w== 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:date:cc:to:from:subject:message-id :arc-authentication-results; bh=Esp/IWw+Sn+pNI7+NymaUTRncpBAVxJiIQfRoyG35Jo=; b=gGV113Smq0o7UwJMrlZggFoniKM+9SVS/086vU45yIyiOPR4bWacRDDW7jY5aR94Y4 dk0A/b2MPsUZ8u/fg/vextUjlFVk+i2ueuNiusR+uXqhIsRkEZAfsEhCkpor4aRiVeVf Wq8GctUmleHSDwxXxke9cmznvfDkcFayvcenbwY2dVmDiYJpQdgbcFOcd0wQQ4azkTsB RM4MXag1yVyBViLohhgfL2x5lBZruZBEpunA9OOpIqIOXNYAjQmhZtKNMVLjuH6IaY1x iUjxEnkUpUcPhIizSds090IDV7fN9P0yxln8IE7lp37duqPPbUHdPqj1pigbSA5TeHFD PBew== 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 u23si1836011pgo.594.2017.11.29.13.03.11; Wed, 29 Nov 2017 13:03:25 -0800 (PST) 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 S1752618AbdK2VC6 (ORCPT + 99 others); Wed, 29 Nov 2017 16:02:58 -0500 Received: from mga14.intel.com ([192.55.52.115]:52951 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752374AbdK2VC4 (ORCPT ); Wed, 29 Nov 2017 16:02:56 -0500 Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2017 13:02:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,339,1508828400"; d="scan'208";a="181715825" Received: from tzanussi-mobl.amr.corp.intel.com (HELO [10.255.78.174]) ([10.255.78.174]) by fmsmga005.fm.intel.com with ESMTP; 29 Nov 2017 13:02:54 -0800 Message-ID: <1511989374.31570.22.camel@tzanussi-mobl.amr.corp.intel.com> Subject: Re: [PATCH v6 29/37] tracing: Add cpu field for hist triggers From: Tom Zanussi To: Namhyung Kim Cc: rostedt@goodmis.org, tglx@linutronix.de, mhiramat@kernel.org, vedang.patel@intel.com, bigeasy@linutronix.de, joel.opensrc@gmail.com, joelaf@google.com, mathieu.desnoyers@efficios.com, baohong.liu@intel.com, rajvi.jingar@intel.com, julia@ni.com, fengguang.wu@intel.com, linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, kernel-team@lge.com Date: Wed, 29 Nov 2017 15:02:54 -0600 In-Reply-To: <20171123052556.GB25472@sejong> References: <20171123052556.GB25472@sejong> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Namhyung, On Thu, 2017-11-23 at 14:25 +0900, Namhyung Kim wrote: > On Fri, Nov 17, 2017 at 02:33:08PM -0600, Tom Zanussi wrote: > > A common key to use in a histogram is the cpuid - add a new cpu > > 'synthetic' field for that purpose. This field is named cpu rather > > than $cpu or $common_cpu because 'cpu' already exists as a special > > filter field and it makes more sense to match that rather than add > > another name for the same thing. > > > > Signed-off-by: Tom Zanussi > > --- > > Documentation/trace/histogram.txt | 17 +++++++++++++++++ > > kernel/trace/trace_events_hist.c | 28 +++++++++++++++++++++++++++- > > 2 files changed, 44 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/trace/histogram.txt b/Documentation/trace/histogram.txt > > index d1d92ed..cd3ec00 100644 > > --- a/Documentation/trace/histogram.txt > > +++ b/Documentation/trace/histogram.txt > > @@ -172,6 +172,23 @@ > > The examples below provide a more concrete illustration of the > > concepts and typical usage patterns discussed above. > > > > + 'special' event fields > > + ------------------------ > > + > > + There are a number of 'special event fields' available for use as > > + keys or values in a hist trigger. These look like and behave as if > > + they were actual event fields, but aren't really part of the event's > > + field definition or format file. They are however available for any > > + event, and can be used anywhere an actual event field could be. > > + 'Special' field names are always prefixed with a '$' character to > > + indicate that they're not normal fields (with the exception of > > + 'cpu', for compatibility with existing filter usage): > > But it also could make a confusion to variables. How about removing > '$' character at all? > I think those are good points - it would be more consistent with the existing cpu, cause less confusion with variable references, and there's only the $common_timestamp so far. The downside would be that users might get confused not finding these fields in the event descriptions, and would basically have to know to look in the documentation to confirm that these are special fields. So unless there are any objections, I'll remove this $special syntax for these. So $common_timestamp will become just common_timestamp and the expression syntax will look like this now, for example: wakeup_lat=common_timestamp.usecs-$ts0:onmax($wakeup_lat).save(...) instead of: wakeup_lat=$common_timestamp.usecs-$ts0:onmax($wakeup_lat).save(...) Also, I've gone through all your other v6 comments and agree with those and have made the suggested changes, so won't comment on the rest of the individual patches. Thanks for the thorough reviews! Tom > > > + > > + $common_timestamp u64 - timestamp (from ring buffer) associated > > + with the event, in nanoseconds. May be > > + modified by .usecs to have timestamps > > + interpreted as microseconds. > > + cpu int - the cpu on which the event occurred. > > > > 6.2 'hist' trigger examples > > --------------------------- > > diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c > > index 121f7ef..afbfa9c 100644 > > --- a/kernel/trace/trace_events_hist.c > > +++ b/kernel/trace/trace_events_hist.c > > @@ -227,6 +227,7 @@ enum hist_field_flags { > > HIST_FIELD_FL_VAR = 1 << 12, > > HIST_FIELD_FL_EXPR = 1 << 13, > > HIST_FIELD_FL_VAR_REF = 1 << 14, > > + HIST_FIELD_FL_CPU = 1 << 15, > > }; > > > > struct var_defs { > > @@ -1177,6 +1178,16 @@ static u64 hist_field_timestamp(struct hist_field *hist_field, > > return ts; > > } > > > > +static u64 hist_field_cpu(struct hist_field *hist_field, > > + struct tracing_map_elt *elt, > > + struct ring_buffer_event *rbe, > > + void *event) > > +{ > > + int cpu = smp_processor_id(); > > + > > + return cpu; > > +} > > + > > static struct hist_field * > > check_field_for_var_ref(struct hist_field *hist_field, > > struct hist_trigger_data *var_data, > > @@ -1622,6 +1633,8 @@ static const char *hist_field_name(struct hist_field *field, > > field_name = hist_field_name(field->operands[0], ++level); > > else if (field->flags & HIST_FIELD_FL_TIMESTAMP) > > field_name = "$common_timestamp"; > > + else if (field->flags & HIST_FIELD_FL_CPU) > > + field_name = "cpu"; > > else if (field->flags & HIST_FIELD_FL_EXPR || > > field->flags & HIST_FIELD_FL_VAR_REF) { > > if (field->system) { > > @@ -2125,6 +2138,15 @@ static struct hist_field *create_hist_field(struct hist_trigger_data *hist_data, > > goto out; > > } > > > > + if (flags & HIST_FIELD_FL_CPU) { > > + hist_field->fn = hist_field_cpu; > > + hist_field->size = sizeof(int); > > + hist_field->type = kstrdup("int", GFP_KERNEL); > > Is it unsigned? > > Thanks, > Namhyung > > > > + if (!hist_field->type) > > + goto free; > > + goto out; > > + } > > + > > if (WARN_ON_ONCE(!field)) > > goto out; > > > > @@ -2343,7 +2365,9 @@ static struct hist_field *parse_var_ref(struct hist_trigger_data *hist_data, > > hist_data->enable_timestamps = true; > > if (*flags & HIST_FIELD_FL_TIMESTAMP_USECS) > > hist_data->attrs->ts_in_usecs = true; > > - } else { > > + } else if (strcmp(field_name, "cpu") == 0) > > + *flags |= HIST_FIELD_FL_CPU; > > + else { > > field = trace_find_event_field(file->event_call, field_name); > > if (!field || !field->size) { > > field = ERR_PTR(-EINVAL); > > @@ -4612,6 +4636,8 @@ static void hist_field_print(struct seq_file *m, struct hist_field *hist_field) > > > > if (hist_field->flags & HIST_FIELD_FL_TIMESTAMP) > > seq_puts(m, "$common_timestamp"); > > + else if (hist_field->flags & HIST_FIELD_FL_CPU) > > + seq_puts(m, "cpu"); > > else if (field_name) { > > if (hist_field->flags & HIST_FIELD_FL_VAR_REF) > > seq_putc(m, '$'); > > -- > > 1.9.3 > > From 1584833298634932995@xxx Thu Nov 23 05:26:52 +0000 2017 X-GM-THRID: 1584401087630036877 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread