From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] Revert arm64 cache geometry
Date: Thu, 29 Oct 2015 11:43:20 +0000 [thread overview]
Message-ID: <56320658.5090106@arm.com> (raw)
In-Reply-To: <20151029112914.GB28221@leverpostej>
On 29/10/15 11:29, Mark Rutland wrote:
> On Wed, Oct 28, 2015 at 02:43:54PM -0700, Alex Van Brunt wrote:
>> This patchset reverts three patches that attempt to query the CPU for cache
>> geometry and then make use of that information. Those patches rely on the
>> NumSets and LineSize fields of CCSIDR to determine the cache geometry. However,
>> the architectural documentation for these registers forbids such use:
>>
>> The parameters NumSets, Associativity, and LineSize in these registers
>> define the architecturally visible parameters that are required for the
>> cache maintenance by Set/Way instructions. They are not guaranteed to
>> represent the actual microarchitectural features of a design. You cannot
>> make any inference about the actual sizes of caches based on these
>> parameters.
>>
>> It is not just theoretical. For example, the Denver CPU will report one set and
>> one way in CCSIDR even though the actual microarchitectural implementation has
>> many sets and many ways.
>>
>> I have two suggestions for how to get the cache geometry on an ARMv8 processor:
>> 1. Specify the information in the device tree. The purpose of the deivce tree
>> is to specify information that software cannot query at run-time. Becuase
>> the architecture does not have an architectural way to query the cache
>> geometry this may be a good fit.
>
> We already have to detect the unification of caches via DT, so the geomtery
> should probably live there too.
>
I agree with that and since we are already exposing cache geometry via
sysfs we need to override with values from DT if found instead of
reverting this completely, so that we don't break any user-space.
--
Regards,
Sudeep
next prev parent reply other threads:[~2015-10-29 11:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 21:43 [PATCH 0/3] Revert arm64 cache geometry Alex Van Brunt
2015-10-28 21:43 ` [PATCH 1/3] Revert "arm64: kernel: add support for cpu cache information" Alex Van Brunt
2015-10-28 21:43 ` [PATCH 2/3] Revert "arm64: don't flag non-aliasing VIPT I-caches as aliasing" Alex Van Brunt
2015-10-28 21:43 ` [PATCH 3/3] Revert "arm64: add helper functions to read I-cache attributes" Alex Van Brunt
2015-10-29 3:22 ` [PATCH 0/3] Revert arm64 cache geometry Ard Biesheuvel
2015-10-29 11:20 ` Mark Rutland
2015-10-29 12:26 ` Ard Biesheuvel
2015-10-29 15:43 ` Russell King - ARM Linux
2015-10-29 16:28 ` Ard Biesheuvel
2015-10-29 23:06 ` Alexander Van Brunt
2015-10-29 22:54 ` Alexander Van Brunt
2015-10-30 11:18 ` Will Deacon
2015-10-29 11:29 ` Mark Rutland
2015-10-29 11:43 ` Sudeep Holla [this message]
2015-10-29 11:40 ` Will Deacon
2015-10-29 23:03 ` Alexander Van Brunt
2015-10-30 11:00 ` Catalin Marinas
2015-10-30 11:10 ` Sudeep Holla
2015-10-30 11:57 ` Catalin Marinas
2015-10-30 12:27 ` 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=56320658.5090106@arm.com \
--to=sudeep.holla@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).