[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YJFjTCsk9dCd6QP7@krava>
Date: Tue, 4 May 2021 17:07:56 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Jin Yao <yao.jin@...ux.intel.com>
Cc: acme@...nel.org, jolsa@...nel.org, peterz@...radead.org,
mingo@...hat.com, alexander.shishkin@...ux.intel.com,
Linux-kernel@...r.kernel.org, ak@...ux.intel.com,
kan.liang@...el.com, yao.jin@...el.com
Subject: Re: [PATCH v1 2/2] perf header: Support hybrid CPU_PMU_CAPS
On Fri, Apr 30, 2021 at 03:46:02PM +0800, Jin Yao wrote:
> On hybrid platform, it may have several cpu pmus, such as,
> "cpu_core" and "cpu_atom". The CPU_PMU_CAPS feature in perf
> header needs to be improved to support multiple cpu pmus.
>
> The new layout in header is defined as:
>
> <nr_caps>
> <caps string>
> <caps string>
> <pmu name>
> <nr of rest pmus>
not sure why is the 'nr of rest pmus' needed
the current format is:
u32 nr_cpu_pmu_caps;
{
char name[];
char value[];
} [nr_cpu_pmu_caps]
I guess we could extend it to:
u32 nr_cpu_pmu_caps;
{
char name[];
char value[];
} [nr_cpu_pmu_caps]
char pmu_name[]
u32 nr_cpu_pmu_caps;
{
char name[];
char value[];
} [nr_cpu_pmu_caps]
char pmu_name[]
...
and we could detect the old format by checking that there's no
pmu name.. but maybe I'm missing something, I did not check deeply,
please let me know
also would be great to move the format change and storing hybrid
pmus in separate patches
thanks,
jirka
Powered by blists - more mailing lists