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=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 55DF8C433E6 for ; Wed, 17 Mar 2021 12:17:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0EA7A64F73 for ; Wed, 17 Mar 2021 12:17:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229549AbhCQMQp (ORCPT ); Wed, 17 Mar 2021 08:16:45 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:48858 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229472AbhCQMQO (ORCPT ); Wed, 17 Mar 2021 08:16:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615983373; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FszNgVMbQS63a+s1/yYr/sdKQFD0RdKs3g1thIm7GaM=; b=dWJJNccO87A7CYK8hcU0BJQfvWsNrFanJ7whEd4b7F73v6LLylsB/QJxeLev9cR/enesx4 BhEno/xKNaAQ7UC5W3o0Ko5GzQ+lXNmzNIyopH1jbibqJC46q7ljF6MxYTmsJHmQPN1BV8 W1ijEZshOal9ldG1OpiWMBvZkpNuZOQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-103-aznJxc56OhGAFbe8fIvmWQ-1; Wed, 17 Mar 2021 08:16:09 -0400 X-MC-Unique: aznJxc56OhGAFbe8fIvmWQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CAFA98189D3; Wed, 17 Mar 2021 12:16:07 +0000 (UTC) Received: from krava (unknown [10.40.194.149]) by smtp.corp.redhat.com (Postfix) with SMTP id 4778C5D9D3; Wed, 17 Mar 2021 12:16:02 +0000 (UTC) Date: Wed, 17 Mar 2021 13:16:01 +0100 From: Jiri Olsa To: Athira Rajeev Cc: Ravi Bangoria , Madhavan Srinivasan , Peter Zijlstra , Kajol Jain , linux-kernel@vger.kernel.org, acme@kernel.org, linux-perf-users@vger.kernel.org, jolsa@kernel.org, linuxppc-dev@lists.ozlabs.org, kan.liang@linux.intel.com Subject: Re: [PATCH 4/4] tools/perf: Support pipeline stage cycles for powerpc Message-ID: References: <1615298640-1529-1-git-send-email-atrajeev@linux.vnet.ibm.com> <1615298640-1529-5-git-send-email-atrajeev@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 17, 2021 at 05:01:27PM +0530, Athira Rajeev wrote: >


On 16-Mar-2021, at 4:48 AM, Jiri Olsa <jolsa@redhat.com> wrote:
=
On Mon, Mar 15, 2021 at 01:22:09PM +0530, Athira Rajeev wrote:

S= NIP

+
+static char *setup_dynamic_sort_= keys(char *str)
+{
+ unsigned int j;
+
+ if (sort__mode =3D=3D SORT_MODE__MEMORY)
= + for (j =3D 0; j <= ; ARRAY_SIZE(dynamic_sort_keys_mem); j++)
+ if (arch_support_dynamic_key(dynamic_sort_keys_mem[j])) {+ str =3D suffix_if_not_in(dynamic_sort= _keys_mem[j], str);
+ if (str =3D=3D N= ULL)
+ <= span class=3D"Apple-tab-span" style=3D"white-space:pre">
return str;
+ }
+
+ return str;
+}
+
static int __setup_sorting(s= truct evlist *evlist)
{
char *str;
@@ -3050,6 +3085,12 @@ static int __setup= _sorting(struct evlist *evlist)
}
}

+ str =3D setup_dynamic_sort_keys(str);
+ if (str =3D=3D NULL) {
+ pr_err("Not enough memory = to setup dynamic sort keys");
+ return -ENOMEM;
+ }

hum, so this is basicaly over= loading the default_mem_sort_order for
architecture, right?

then = I think it'd be easier just overload default_mem_sort_order directly
I was thinking more about adding extra (arch specific) loop to
sort_dim= ension__add or somehow add arch's specific stuff to
memory_sort_dimensio= ns

Hi Jiri,

Above patch was to append additional= sort keys to sort order based on
sort mode and architecture support. I = had initially thought of defining two
orders ( say default_mem_sort_orde= r plus mem_sort_order_pstage ). But if
new sort keys gets added for mem = mode in future, we will need to keep
updating both orders. So preferred = the approach of "appending" supported sort
keys to default order.
Following your thought on using "sort_dimension__add", I tried below appro= ach
which is easier. The new sort dimension "p_stage_cyc" is presently o= nly supported
on powerpc. For unsupported platforms, we don't want to di= splay it
in the perf report output columns. Hence added check in sort_di= mension__add()
and skip the sort key incase its not applicable for parti= cular arch.

Please help to check if below approach looks fine.

diff --git a/tools/perf/arch/powerpc/util/event.c b/tools/perf/arch/p= owerpc/util/event.c
index b80fbee83b6e..7205767d75eb 100644
--- a/too= ls/perf/arch/powerpc/util/event.c
+++ b/tools/perf/arch/powerpc/util/eve= nt.c
@@ -44,3 +44,10 @@ const char *arch_perf_header_entry__add(const ch= ar *se_header)
r= eturn "Dispatch Cyc";
return se_header;
}
+
+int arch_support_sort_key(= const char *sort_key)
+{
+ if (!strcmp(sort_key, "p_stage_cyc"))
+ return 1;
+ return 0;
+}
diff --g= it a/tools/perf/util/event.h b/tools/perf/util/event.h
index 65f89e80916= f..612a92aaaefb 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf= /util/event.h
@@ -429,5 +429,6 @@ char *get_page_size_name(u64 size, cha= r *str);
void arch_perf_parse_sample_weight(struct perf_sample *data, c= onst __u64 *array, u64 type);
void arch_perf_synthesize_sample_weight(c= onst struct perf_sample *data, __u64 *array, u64 type);
const char *arc= h_perf_header_entry__add(const char *se_header);
+int arch_support_sort_= key(const char *sort_key);

#endif /* __PERF_RECORD_H */
diff --g= it a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index cbb3899e7eca.= =2Ed8b0b0b43a81 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/= util/sort.c
@@ -47,6 +47,7 @@ regex_t ignore_callees_regex;
int have_ignore_callees =3D 0;
enum sort_mode<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> sort__mode = =3D SORT_MODE__NORMAL;
const char *dynamic_headers[] =3D {"local_ins_lat", "p_st= age_cyc"};
+const char *arch_specific_sort_keys[] =3D {"p_stage_cyc"};

/*  * Replaces all occurrences of a char used with the:
@@ -1837,6 = +1838,11 @@ struct sort_dimension {
int taken;
};

+int __weak arch_support_sort_key(const char *sort_= key __maybe_unused)
+{
+ return 0;
+}
+
const char * __weak arch_perf_= header_entry__add(const char *se_header)
{
return se_header;
@@ -2773,6 +2= 779,18 @@ int sort_dimension__add(struct perf_hpp_list *list, const char *t= ok,
{
unsigned int i, j;

+ /* Check to see if there are any arch specific
+
* sort dimen= sions not applicable for the current
+ * architecture. If so, Skip that sort key s= ince
+ = * we don't want to display it in the output fields.
+ */
+ for (j =3D 0; j < ARRAY_SIZE= (arch_specific_sort_keys); j++) {
+ if (!strcmp(arch_specific_sort_keys[j], tok) &&<= br>+ !arch_support_sort_key(tok)) {
+<= span class=3D"Apple-tab-span" style=3D"white-space:pre">
return 0;
+ }
+ }
+
for (i =3D 0; i < ARRAY_SIZE(common_s= ort_dimensions); i++) {
= struct sort_dimension *sd =3D &common_sort_dimensions[i];
=E2=80=94
2.26.2

Thanks
Athira


jirka


>=20 apart from the html content, looks ok ;-) jirka