mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Clark <james.clark@linaro.org>
To: Namhyung Kim <namhyung@kernel.org>, Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Sun Haiyong <sunhaiyong@loongson.cn>,
	Yanteng Si <siyanteng@loongson.cn>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/5] perf cpumap: If the die_id is missing use socket/physical_package_id
Date: Fri, 20 Dec 2024 10:28:50 +0000	[thread overview]
Message-ID: <462b0262-305b-4ed2-9c1c-2afeaec8646e@linaro.org> (raw)
In-Reply-To: <Z2SV2A9C6V65YL3x@google.com>



On 19/12/2024 9:53 pm, Namhyung Kim wrote:
> On Thu, Dec 19, 2024 at 09:20:39AM -0800, Ian Rogers wrote:
>> On Wed, Dec 18, 2024 at 9:32 PM Namhyung Kim <namhyung@kernel.org> wrote:
>>>
>>> On Wed, Dec 18, 2024 at 09:42:27AM -0800, Ian Rogers wrote:
>>>> On Wed, Dec 18, 2024 at 4:04 AM James Clark <james.clark@linaro.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 16/12/2024 11:24 pm, Ian Rogers wrote:
>>>>>> An error value for a missing die_id may be written into things like
>>>>>> the cpu_topology_map. As the topology needs to be fully written out,
>>>>>> including the die_id, to allow perf.data file features to be aligned
>>>>>> we can't allow error values to be written out. Instead base the
>>>>>> missing die_id value off of the socket/physical_package_id assuming
>>>>>> they correlate 1:1.
>>>>>>
>>>>>> Signed-off-by: Ian Rogers <irogers@google.com>
>>>>>> ---
>>>>>>    tools/perf/util/cpumap.c | 3 ++-
>>>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
>>>>>> index 27094211edd8..d362272f8466 100644
>>>>>> --- a/tools/perf/util/cpumap.c
>>>>>> +++ b/tools/perf/util/cpumap.c
>>>>>> @@ -283,7 +283,8 @@ int cpu__get_die_id(struct perf_cpu cpu)
>>>>>>    {
>>>>>>        int value, ret = cpu__get_topology_int(cpu.cpu, "die_id", &value);
>>>>>>
>>>>>> -     return ret ?: value;
>>>>>> +        /* If die_id is missing fallback on using the socket/physical_package_id. */
>>>>>> +     return ret || value < 0 ? cpu__get_socket_id(cpu) : value;
>>>>>>    }
>>>>>>
>>>>>>    struct aggr_cpu_id aggr_cpu_id__die(struct perf_cpu cpu, void *data)
>>>>>
>>>>> Hi Ian,
>>>>>
>>>>> I sent a fix for the same or a similar problem here [1]. For this one
>>>>> I'm not sure why we'd want to use the socket ID for die when it's always
>>>>> been 0 for not present. I wonder if this change is mingling two things:
>>>>> fixing the negative error value appearing and replacing die with socket ID.
>>>>>
>>>>> Personally I would prefer to keep the 0 to fix the error value, that way
>>>>> nobody gets surprised by the change.
>>>>>
>>>>> Also it looks like cpu__get_cluster_id() can suffer from the same issue,
>>>>> and if we do it this way we should drop these as they aren't valid anymore:
>>>>>
>>>>>          /* There is no die_id on legacy system. */
>>>>>          if (die < 0)
>>>>>                  die = 0;
>>>>
>>>> I think this breaks the assumption here:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/tests/expr.c?h=perf-tools-next#n244
 >>>>>> Hmm.. I'm not sure how it worked before.  The code is already 
there and
>>> it just changed the condition from == -1 to < 0, right?
>>
>> You'd need to be testing on a multi-socket machine to see the issue.
>> If you had say a dual socket Ampere chip and the die_id was missing,
>> does it make sense for there to be two sockets/packages but only 1
>> die? I think it is best we assume 1 die per socket when the die_id is
>> missing, and to some crippled extent (because of the s390 workaround)
>> the expr test is doing the sanity check.
> 
> AFAICS die ID is always used with socket ID already so I guess it means
> an ID inside a socket.
> 
> Thanks,
> Namhyung
> 

Don't we then need to update has_die_topology() to always return true if 
we're using socket ID as a placeholder? And the #num_dies expression 
should potentially become non-zero for consistency?

Seems like there are two options:

  - Fully support "no die reported"
   * -errno is saved into the topology header, but it's still converted
     to 0 for Perf stat aggregation and display
   * #num_dies == 0 as it currently is
   * Anywhere else die is used it's checked for error values first

  - Replace die with package
    * #num_dies == #num_packages
    * has_die_topology() == true
    * delete code to display die as 0 in perf stat

With this patch we get somewhere between the two.

Thanks
James


  reply	other threads:[~2024-12-20 10:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-16 23:24 [PATCH v3 0/5] perf file align features, avoid UB Ian Rogers
2024-12-16 23:24 ` [PATCH v3 1/5] perf cpumap: If the die_id is missing use socket/physical_package_id Ian Rogers
2024-12-18 12:04   ` James Clark
2024-12-18 17:42     ` Ian Rogers
2024-12-19  5:32       ` Namhyung Kim
2024-12-19 17:20         ` Ian Rogers
2024-12-19 21:53           ` Namhyung Kim
2024-12-20 10:28             ` James Clark [this message]
2024-12-20 17:45               ` Ian Rogers
2024-12-16 23:24 ` [PATCH v3 2/5] perf header: Write out even empty die_cpus_list Ian Rogers
2024-12-16 23:24 ` [PATCH v3 3/5] perf synthetic-events: Ensure features are aligned Ian Rogers
2024-12-19  1:08   ` Namhyung Kim
2024-12-19  1:29     ` Ian Rogers
2024-12-19  5:29       ` Namhyung Kim
2024-12-16 23:24 ` [PATCH v3 4/5] perf machine: Avoid UB by delaying computing branch entries Ian Rogers
2024-12-16 23:24 ` [PATCH v3 5/5] perf record: Assert synthesized events are 8-byte aligned Ian Rogers

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=462b0262-305b-4ed2-9c1c-2afeaec8646e@linaro.org \
    --to=james.clark@linaro.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=siyanteng@loongson.cn \
    --cc=sunhaiyong@loongson.cn \
    /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

all inboxes | Powered by JetHome®