linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/2] ACPI / PPTT: ids for caches
Date: Mon, 8 Oct 2018 10:26:05 +0100	[thread overview]
Message-ID: <9b534013-f45e-2348-9a4f-87d3db2b4527@arm.com> (raw)
In-Reply-To: <4084f44a-f1ed-e027-c838-946bda2f0dc9@codeaurora.org>

Hi Jeffrey,

On 05/10/2018 17:39, Jeffrey Hugo wrote:
> On 10/5/2018 9:54 AM, James Morse wrote:
>> The problem is generating these numbers if only some of the CPUs are online, or
>> if the acpi tables are generated by firmware at power-on and have a different
>> layout every time.
>> We don't even want to rely on linux's cpu numbering.
>>
>> The suggestion here is to use the smallest MPIDR, as that's as hardware property
>> that won't change even if the tables are generated differently every boot.
> 
> I can't think of a reason why affinity level 0 would ever change for a

affinity level of what? The caches? Sure, that should be impossible to change.


> particular thread or core (SMT vs non-SMT), however none of the other affinity
> levels have a well defined meaning (implementation dependent), and could very
> well change boot to boot.

Ah, you mean the level numbers. Yes, these are (quasi) discovered from the
table, so can't be relied on.

If you insert a new level then this would shuffle the user-visible indexes and
levels. I would argue this is no longer the same hardware.

Doing this may already break resctrl as the 'L2' and 'L3' numbers are part of
the ABI.

The ids generated would still be unique for a level.


> I would strongly avoid using MPIDR, particularly for the usecase you've described.

Is there an alternative? It needs to be a hardware property to insulate us from
the tables being re-generated.

I agree the MPIDR numbers are likely to be ugly, (I don't really care...).
The u32 id being full from day 1 is more of a problem.


>> Assuming two clusters in your example above, it would look like:
>>
>> | CPU0/1 (cluster 0) L2 - 0x0
>> | CPU2/3 (cluster 1) L2 - 0x100
>> |??????????????????? L3 - 0x0
> 
> Thanks for the clarification.? I think I've got enough to wrap my head around
> this.? Let me think on it a bit to see if I can come up with a suggestion (we
> can debate how good it is).

Sounds good.


Thanks!

James

  reply	other threads:[~2018-10-08  9:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-05 15:02 [RFC PATCH 0/2] ACPI / PPTT: ids for caches James Morse
2018-10-05 15:02 ` [RFC PATCH 1/2] ACPI / processor: Add helper to convert acpi_id to a phys_cpuid James Morse
2018-10-05 15:02 ` [RFC PATCH 2/2] ACPI / PPTT: cacheinfo: Label caches based on fw_token James Morse
2018-10-09 16:45   ` Jeremy Linton
2018-10-09 17:58     ` James Morse
2018-10-09 18:34       ` Jeffrey Hugo
2018-10-10  9:46         ` Sudeep Holla
2018-10-10 14:16           ` Jeffrey Hugo
2019-06-17  8:28   ` Shameerali Kolothum Thodi
2019-06-19 13:31     ` James Morse
2018-10-05 15:20 ` [RFC PATCH 0/2] ACPI / PPTT: ids for caches Jeffrey Hugo
2018-10-05 15:54   ` James Morse
2018-10-05 16:39     ` Jeffrey Hugo
2018-10-08  9:26       ` James Morse [this message]
2018-10-10 16:19         ` Jeffrey Hugo

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=9b534013-f45e-2348-9a4f-87d3db2b4527@arm.com \
    --to=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).