Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Radu Rendec <rrendec@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Pierre Gondois <Pierre.Gondois@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 0/3] arch_topology: Pre-allocate cacheinfo from primary CPU
Date: Wed, 12 Apr 2023 14:57:56 -0400	[thread overview]
Message-ID: <20230412185759.755408-1-rrendec@redhat.com> (raw)

Commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")
tries to build the cacheinfo from the primary CPU prior to secondary
CPUs boot, if the DT/ACPI description contains cache information.
However, if such information is not present, it still reverts to the old
behavior, which allocates the cacheinfo memory on each secondary CPU. On
RT kernels, this triggers a "BUG: sleeping function called from invalid
context" because the allocation is done before preemption is first
enabled on the secondary CPU.

The solution is to add cache information to DT/ACPI, but at least on
arm64 systems this can be avoided by leveraging automatic detection
(through the CLIDR_EL1 register), which is already implemented but
currently doesn't work on RT kernels for the reason described above.

This patch series attempts to enable automatic detection for RT kernels
when no DT/ACPI cache information is available, by pre-allocating
cacheinfo memory on the primary CPU.

The first patch adds an architecture independent infrastructure that
allows architecture specific code to take an early guess at the number
of cache leaves of the secodary CPUs, while it runs in preemptible
context on the primary CPU. At the same time, it gives architecture
specific code the opportunity to go back later, while it runs on the
secondary CPU, and reallocate the cacheinfo memory if the initial guess
proves to be wrong.

The second patch leverages the infrastructure implemented in the first
patch and enables early cache depth detection for arm64.

The third patch addresses a specific issue on ACPI systems with no PPTT.
This issue came up during review/testing of v3.

The patch series is based on an RFC patch that was posted to the
linux-arm-kernel mailing list and discussed with a smaller audience:
https://lore.kernel.org/all/20230323224242.31142-1-rrendec@redhat.com/

Changes to v3:
* Rebase on top of v6.3-rc6 to avoid a (trivial) merge conflict.
* Add patch #3 (brief description included above).
* Add "Reviewed-by: Pierre Gondois" tag to all patches.
* Rename the new field that is added to struct cpu_cacheinfo from
  early_arch_info to early_ci_levels to better reflect what it does.
* Use local variables in the new detect_cache_level() function. That way
  the code is easier to read and the original level/leaves algorithm is
  unchanged, which also makes the patch clearer.

Changes to v2:
* Address minor coding style issue (unbalanced braces).
* Move cacheinfo reallocation logic from detect_cache_attributes() to a
  new function to improve code readability.
* Minor fix to cacheinfo reallocation logic to avoid a new detection of
  the cache level if/when detect_cache_attributes() is called again.

Radu Rendec (3):
  cacheinfo: Add arch specific early level initializer
  cacheinfo: Add arm64 early level initializer implementation
  cacheinfo: Allow early level detection when DT/ACPI info is
    missing/broken

 arch/arm64/kernel/cacheinfo.c | 25 ++++++++++--
 drivers/base/arch_topology.c  |  4 +-
 drivers/base/cacheinfo.c      | 75 +++++++++++++++++++++++++----------
 include/linux/cacheinfo.h     |  2 +
 4 files changed, 79 insertions(+), 27 deletions(-)

-- 
2.39.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2023-04-12 18:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12 18:57 Radu Rendec [this message]
2023-04-12 18:57 ` [PATCH v4 1/3] cacheinfo: Add arch specific early level initializer Radu Rendec
     [not found]   ` <20230510191207.GA18514@ranerica-svr.sc.intel.com>
2023-05-15  9:36     ` Sudeep Holla
2023-05-18  1:27       ` Ricardo Neri
2023-05-18  9:34         ` Sudeep Holla
2023-05-31 12:22           ` Sudeep Holla
2023-05-31 17:03             ` Ricardo Neri
2023-08-07 23:23               ` Ricardo Neri
     [not found]     ` <b49e241d3ea8c679b81134e22c908ca64aeca18c.camel@redhat.com>
     [not found]       ` <20230511000058.GD18514@ranerica-svr.sc.intel.com>
     [not found]         ` <9020807789b70db0d84d142cbfed2bd8868f366a.camel@redhat.com>
2023-05-19 21:44           ` Ricardo Neri
2023-05-19 22:02             ` Radu Rendec
2023-04-12 18:57 ` [PATCH v4 2/3] cacheinfo: Add arm64 early level initializer implementation Radu Rendec
2023-04-13 10:22   ` Sudeep Holla
2023-04-13 14:45     ` Will Deacon
2023-04-13 15:05       ` Sudeep Holla
2023-04-14 12:46         ` Will Deacon
2023-04-12 18:57 ` [PATCH v4 3/3] cacheinfo: Allow early level detection when DT/ACPI info is missing/broken Radu Rendec
2023-04-17 14:07 ` [PATCH v4 0/3] arch_topology: Pre-allocate cacheinfo from primary CPU Sudeep Holla

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=20230412185759.755408-1-rrendec@redhat.com \
    --to=rrendec@redhat.com \
    --cc=Pierre.Gondois@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=will@kernel.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