From: Swapnil Sapkal <swapnil.sapkal@amd.com>
To: Thomas Richter <tmricht@linux.ibm.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 16:49:04 +0530 [thread overview]
Message-ID: <1e6db624-aeb9-4d9a-9ecd-ea1524e00d1e@amd.com> (raw)
In-Reply-To: <64b353ab-6079-49fb-8495-06087e6686fb@linux.ibm.com>
Hi Thomas,
On 17-06-2026 12:14, Thomas Richter wrote:
> 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.
Sure, I will modify the documenation accordingly.
> 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.
I appreciate you bringing that to my attention.
>
>> --
>> Thanks and Regards,
>> Swapnil
>>
>
>
> Thanks.
>
>
--
Thanks and Regards,
Swapnil
prev parent reply other threads:[~2026-06-17 11:19 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
2026-06-17 11:19 ` Swapnil Sapkal [this message]
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=1e6db624-aeb9-4d9a-9ecd-ea1524e00d1e@amd.com \
--to=swapnil.sapkal@amd.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=tmricht@linux.ibm.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