From: Sudeep Holla <sudeep.holla@arm.com>
To: Radu Rendec <rrendec@redhat.com>, Will Deacon <will@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Pierre Gondois <Pierre.Gondois@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 2/3] cacheinfo: Add arm64 early level initializer implementation
Date: Thu, 13 Apr 2023 11:22:26 +0100 [thread overview]
Message-ID: <20230413102226.yzzd6iccqeamheas@bogus> (raw)
In-Reply-To: <20230412185759.755408-3-rrendec@redhat.com>
Hi Will,
On Wed, Apr 12, 2023 at 02:57:58PM -0400, Radu Rendec wrote:
> This patch adds an architecture specific early cache level detection
> handler for arm64. This is basically the CLIDR_EL1 based detection that
> was previously done (only) in init_cache_level().
>
> This is part of a patch series that attempts to further the work in
> commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU").
> Previously, in the absence of any DT/ACPI cache info, architecture
> specific cache detection and info allocation for secondary CPUs would
> happen in non-preemptible context during early CPU initialization and
> trigger a "BUG: sleeping function called from invalid context" splat on
> an RT kernel.
>
> This patch does not solve the problem completely for RT kernels. It
> relies on the assumption that on most systems, the CPUs are symmetrical
> and therefore have the same number of cache leaves. The cacheinfo memory
> is allocated early (on the primary CPU), relying on the new handler. If
> later (when CLIDR_EL1 based detection runs again on the secondary CPU)
> the initial assumption proves to be wrong and the CPU has in fact more
> leaves, the cacheinfo memory is reallocated, and that still triggers a
> splat on an RT kernel.
>
> In other words, asymmetrical CPU systems *must* still provide cacheinfo
> data in DT/ACPI to avoid the splat on RT kernels (unless secondary CPUs
> happen to have less leaves than the primary CPU). But symmetrical CPU
> systems (the majority) can now get away without the additional DT/ACPI
> data and rely on CLIDR_EL1 based detection.
>
If you are okay with the change, can I have your Acked-by, so that I can
route this via Greg's tree ?
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-13 10:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 18:57 [PATCH v4 0/3] arch_topology: Pre-allocate cacheinfo from primary CPU Radu Rendec
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 [this message]
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=20230413102226.yzzd6iccqeamheas@bogus \
--to=sudeep.holla@arm.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=rrendec@redhat.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