From: Thomas Richter <tmricht@linux.ibm.com>
To: Swapnil Sapkal <swapnil.sapkal@amd.com>,
Ian Rogers <irogers@google.com>,
Namhyung Kim <namhyung@kernel.org>
Cc: Jan Polensky <japo@linux.ibm.com>,
Sumanth Korikkar <sumanthk@linux.ibm.com>,
"linux-perf-use." <linux-perf-users@vger.kernel.org>,
ravi.bangoria@amd.com
Subject: Re: Missing information in HEADER_CPU_DOMAIN_INFO
Date: Wed, 17 Jun 2026 08:44:29 +0200 [thread overview]
Message-ID: <64b353ab-6079-49fb-8495-06087e6686fb@linux.ibm.com> (raw)
In-Reply-To: <46b69b4c-b7d7-4155-93aa-62d2c34e0105@amd.com>
On 6/16/26 15:21, Swapnil Sapkal wrote:
> Hi Thomas,
>
> Thank you for pointing this issues.
>
> On 12-06-2026 19:03, Thomas Richter wrote:
>>
>> Hi Swapnil,
>>
>> Commit d40c68a49f69 ("perf header: Support CPU DOMAIN relation info")
>> introduced the HEADER_CPU_DOMAIN_INFO bit and the necessary data.
>>
>> However two issues came to my attention.
>>
>> 1. The documentation is incomplete.
>> File Documentation/perf.data-file-format.txt differs from the data written
>> in function write_cpu_domain_info().
>> The first two values written to the header section are schedstat_version
>> and max_sched_domains. They are missing in the documentation.
>>
>
> I agree with this. I will update the documentation for the same.
Great Thanks
>
>> 2. The function write_cpu_domain_info() writes a variable amount of data,
>> but does not indicate how much CPU members have actually been written.
>> This makes it much harder to read back that data from a perf.data file,
>> because the reader does not know in advance how much data to read.
>> Since the data structures also contain strings, the file section size does
>> not help at all, because strings are of variable size.
>>
>> In my opinion the structure should contain the number of CPU data to read.
>> My suggestion:
>> Modify structure cpu_domain_info, which contains the
>> missing schedstat_version and max_sched_domains fields and contains the
>> number of CPU records actually written to that header section.
>> Here is an idea:
>>
>> HEADER_CPU_DOMAIN_INFO = 32,
>>
>> List of cpu-domain relation info. The format of the data is as below.
>>
>> struct domain_info {
>> int domain;
>> char dname[];
>> char cpumask[];
>> char cpulist[];
>> };
>>
>> struct cpu_domain_info {
>> int schedstat_version;
>> int max_sched_domains;
>> int nr_cpus; <--- new
>> struct {
>> u32 cpu;
>> u32 nr_domains;
>> struct domain_info [nr_domains];
>> } [nr_cpus];
>> };
>>
>> The above syntax is also in sync the other sections of that documentation file.
>>
>> What do you think?
>>
>
> I agree with you on addition of schedstat_version and max_sched_domains fields to struct cpu_domain_info.
>
> Regarding nr_cpus: since /proc/schedstat only contains stats for online CPUs, the number of CPU stats written equals env->nr_cpus_online. This information is already available via HEADER_NRCPUS, so I didn't include it in cpu_domain_info. Please let me know if I've overlooked something.
>
Ah, now I get it. This is fine with me but should be mentioned in the documentation as well.
See header feature HEADER_CPU_TOPOLOGY documentation.
There is a similar situation and is expained in the comment:
struct {
uint32_t core_id;
uint32_t socket_id;
} cpus[nr]; /* Variable length records */
/* 'nr' comes from previously processed HEADER_NRCPUS's nr_cpu_avail */ <--- here
So the reader is aware of the cross reference and what value to use when reading the feature file section.
> --
> Thanks and Regards,
> Swapnil
>
Thanks.
--
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
next prev parent reply other threads:[~2026-06-17 6:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 13:33 Missing information in HEADER_CPU_DOMAIN_INFO Thomas Richter
2026-06-16 13:21 ` Swapnil Sapkal
2026-06-17 6:44 ` Thomas Richter [this message]
2026-06-17 11:19 ` Swapnil Sapkal
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=64b353ab-6079-49fb-8495-06087e6686fb@linux.ibm.com \
--to=tmricht@linux.ibm.com \
--cc=irogers@google.com \
--cc=japo@linux.ibm.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@kernel.org \
--cc=ravi.bangoria@amd.com \
--cc=sumanthk@linux.ibm.com \
--cc=swapnil.sapkal@amd.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