From: "Jin, Yao" <yao.jin@linux.intel.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org,
mingo@redhat.com, alexander.shishkin@linux.intel.com,
Linux-kernel@vger.kernel.org, ak@linux.intel.com,
kan.liang@intel.com, yao.jin@intel.com
Subject: Re: [PATCH v1 1/2] perf header: Support HYBRID_TOPOLOGY feature
Date: Thu, 6 May 2021 10:01:06 +0800 [thread overview]
Message-ID: <1d256f3e-14b3-0c37-610a-2b3777827d95@linux.intel.com> (raw)
In-Reply-To: <YJFgC9tS9m9/DJP8@krava>
Hi Jiri,
On 5/4/2021 10:54 PM, Jiri Olsa wrote:
> On Fri, Apr 30, 2021 at 03:46:01PM +0800, Jin Yao wrote:
>
> SNIP
>
>> +static int write_hybrid_topology(struct feat_fd *ff,
>> + struct evlist *evlist __maybe_unused)
>> +{
>> + struct hybrid_topology *tp;
>> + int ret;
>> + u32 i;
>> +
>> + tp = hybrid_topology__new();
>> + if (!tp)
>> + return -1;
>> +
>> + ret = do_write(ff, &tp->nr, sizeof(u32));
>> + if (ret < 0)
>> + goto err;
>> +
>> + for (i = 0; i < tp->nr; i++) {
>> + struct hybrid_topology_node *n = &tp->nodes[i];
>> +
>> + ret = do_write_string(ff, n->pmu_name);
>> + if (ret < 0)
>> + goto err;
>> +
>> + ret = do_write_string(ff, n->cpus);
>> + if (ret < 0)
>> + goto err;
>> + }
>> +
>> + ret = 0;
>> +
>> +err:
>> + hybrid_topology__delete(tp);
>> + return ret;
>> +}
>> +
>> static int write_dir_format(struct feat_fd *ff,
>> struct evlist *evlist __maybe_unused)
>> {
>> @@ -1623,6 +1657,19 @@ static void print_clock_data(struct feat_fd *ff, FILE *fp)
>> clockid_name(clockid));
>> }
>>
>> +static void print_hybrid_topology(struct feat_fd *ff, FILE *fp)
>> +{
>> + int i;
>> + struct hybrid_node *n;
>> +
>> + for (i = 0; i < ff->ph->env.nr_hybrid_nodes; i++) {
>> + n = &ff->ph->env.hybrid_nodes[i];
>> +
>> + fprintf(fp, "# %s cpu list : ", n->pmu_name);
>> + cpu_map__fprintf(n->map, fp);
>
> do you plan to do anything else with n->map in the future?
> because right now you could just print the stored cpus string no?
> it should be already in the cpumask shape
>
> jirka
>
Yes, you are right, we don't need to use n->map at least now.
Following code should be much simpler.
+struct hybrid_node {
+ char *pmu_name;
+ char *cpus;
+};
+static int process_hybrid_topology(struct feat_fd *ff,
+ void *data __maybe_unused)
+{
+ struct hybrid_node *nodes, *n;
+ u32 nr, i;
+
+ /* nr nodes */
+ if (do_read_u32(ff, &nr))
+ return -1;
+
+ nodes = zalloc(sizeof(*nodes) * nr);
+ if (!nodes)
+ return -ENOMEM;
+
+ for (i = 0; i < nr; i++) {
+ n = &nodes[i];
+
+ n->pmu_name = do_read_string(ff);
+ if (!n->pmu_name)
+ goto error;
+
+ n->cpus = do_read_string(ff);
+ if (!n->cpus)
+ goto error;
+ }
+
+ ff->ph->env.nr_hybrid_nodes = nr;
+ ff->ph->env.hybrid_nodes = nodes;
+ return 0;
+
+error:
...
+static void print_hybrid_topology(struct feat_fd *ff, FILE *fp)
+{
+ int i;
+ struct hybrid_node *n;
+
+ for (i = 0; i < ff->ph->env.nr_hybrid_nodes; i++) {
+ n = &ff->ph->env.hybrid_nodes[i];
+ fprintf(fp, "# %s cpu list : %s\n", n->pmu_name, n->cpus);
+ }
+}
Thanks
Jin Yao
next prev parent reply other threads:[~2021-05-06 2:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-30 7:46 [PATCH v1 1/2] perf header: Support HYBRID_TOPOLOGY feature Jin Yao
2021-04-30 7:46 ` [PATCH v1 2/2] perf header: Support hybrid CPU_PMU_CAPS Jin Yao
2021-05-04 15:07 ` Jiri Olsa
2021-05-06 4:59 ` Jin, Yao
2021-05-06 13:22 ` Jiri Olsa
2021-05-06 14:43 ` Jin, Yao
2021-05-10 13:11 ` Jiri Olsa
2021-05-11 1:15 ` Jin, Yao
2021-05-03 15:18 ` [PATCH v1 1/2] perf header: Support HYBRID_TOPOLOGY feature Arnaldo Carvalho de Melo
2021-05-04 2:03 ` Jin, Yao
2021-05-04 14:54 ` Jiri Olsa
2021-05-06 2:01 ` Jin, Yao [this message]
2021-05-04 14:56 ` Jiri Olsa
2021-05-04 19:28 ` Arnaldo Carvalho de Melo
2021-05-04 19:37 ` Jiri Olsa
2021-05-05 13:49 ` Arnaldo Carvalho de Melo
2021-05-05 20:28 ` Jiri Olsa
2021-05-06 2:22 ` Jin, Yao
2021-05-06 2:17 ` Jin, Yao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d256f3e-14b3-0c37-610a-2b3777827d95@linux.intel.com \
--to=yao.jin@linux.intel.com \
--cc=Linux-kernel@vger.kernel.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kan.liang@intel.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=yao.jin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).