[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM9d7cgRb6_jFXCfoZZ+=K5WSH42hj4U2ZH-i-4oZTMKw+LAiA@mail.gmail.com>
Date: Thu, 1 Sep 2022 23:29:22 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Andi Kleen <ak@...ux.intel.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Thomas Richter <tmricht@...ux.ibm.com>,
James Clark <james.clark@....com>,
Miaoqian Lin <linmq006@...il.com>,
John Garry <john.garry@...wei.com>,
Zhengjun Xing <zhengjun.xing@...ux.intel.com>,
Florian Fischer <florian.fischer@...q.space>,
linux-perf-users <linux-perf-users@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
perry.taylor@...el.com, caleb.biggers@...el.com,
kshipra.bopardikar@...el.com, ahmad.yasin@...el.com,
Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH v2 4/7] perf topology: Add core_wide
Hi Ian,
On Wed, Aug 31, 2022 at 10:50 AM Ian Rogers <irogers@...gle.com> wrote:
>
> It is possible to optimize metrics when all SMT threads (CPUs) on a
> core are measuring events in system wide mode. For example, TMA
> metrics defines CORE_CLKS for Sandybrdige as:
>
> if SMT is disabled:
> CPU_CLK_UNHALTED.THREAD
> if SMT is enabled and recording on all SMT threads:
> CPU_CLK_UNHALTED.THREAD_ANY / 2
> if SMT is enabled and not recording on all SMT threads:
> (CPU_CLK_UNHALTED.THREAD/2)*
> (1+CPU_CLK_UNHALTED.ONE_THREAD_ACTIVE/CPU_CLK_UNHALTED.REF_XCLK )
>
> That is two more events are necessary when not gathering counts on all
> SMT threads. To distinguish all SMT threads on a core vs system wide
> (all CPUs) call the new property core wide. Add a core wide test that
> determines the property from user requested CPUs, the topology and
> system wide. System wide is required as other processes running on a
> SMT thread will change the counts.
>
> Signed-off-by: Ian Rogers <irogers@...gle.com>
> ---
[SNIP]
> diff --git a/tools/perf/util/smt.c b/tools/perf/util/smt.c
> index ce90c4ee4138..994e9e418227 100644
> --- a/tools/perf/util/smt.c
> +++ b/tools/perf/util/smt.c
> @@ -21,3 +21,17 @@ bool smt_on(const struct cpu_topology *topology)
> cached = true;
> return cached_result;
> }
> +
> +bool core_wide(bool system_wide, const char *user_requested_cpu_list,
> + const struct cpu_topology *topology)
> +{
> + /* If not everything running on a core is being recorded then we can't use core_wide. */
> + if (!system_wide)
> + return false;
I'm not sure if it's correct. Wouldn't it be ok if it runs on all
threads in a core
even if system wide is off? I thought that's what the below code checks.
In fact I thought the opposite logic like
if (system_wide)
return true;
But it seems the code allows to have cpu_list in the system wide mode.
Then it also needs to check the user requested cpus being NULL.
(IMHO system_wide should be cleared when it has a cpu list...)
if (system_wide && !user_requested_cpu_list)
return true;
And if we have a target pointer, we could add this too.
if (!target__has_cpu(target))
return false;
Thanks,
Namhyung
> +
> + /* Cheap case that SMT is disabled and therefore we're inherently core_wide. */
> + if (!smt_on(topology))
> + return true;
> +
> + return cpu_topology__core_wide(topology, user_requested_cpu_list);
> +}
> diff --git a/tools/perf/util/smt.h b/tools/perf/util/smt.h
> index e26999c6b8d4..ae9095f2c38c 100644
> --- a/tools/perf/util/smt.h
> +++ b/tools/perf/util/smt.h
> @@ -7,4 +7,11 @@ struct cpu_topology;
> /* Returns true if SMT (aka hyperthreading) is enabled. */
> bool smt_on(const struct cpu_topology *topology);
>
> +/*
> + * Returns true when system wide and all SMT threads for a core are in the
> + * user_requested_cpus map.
> + */
> +bool core_wide(bool system_wide, const char *user_requested_cpu_list,
> + const struct cpu_topology *topology);
> +
> #endif /* __SMT_H */
> --
> 2.37.2.672.g94769d06f0-goog
>
Powered by blists - more mailing lists