Linux Perf Users
 help / color / mirror / Atom feed
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

      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