linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] Revert arm64 cache geometry
Date: Thu, 29 Oct 2015 15:43:46 +0000	[thread overview]
Message-ID: <20151029154346.GL8644@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAKv+Gu-CgXU4O8SymcjmCYZqyAa0PZbJXwNqXfuCamxYY9C8GA@mail.gmail.com>

On Thu, Oct 29, 2015 at 12:22:51PM +0900, Ard Biesheuvel wrote:
> Fair enough. It is a bit disappointing that we cannot trust these
> values, but if the architecture does not mandate their accuracy, we
> obviously should not be using them in the way that we are.
> 
> I think we have similar code in the ARM tree, so we should probably
> make some changes there as well.

I've opposed exporting the cache dimensions to userspace for several
reasons:

* it will become a nightmare with the various different register formats
  to properly decode these values
* older CPUs don't have the cache ID registers, so we'd need to augment
  any export with additional static configuration somehow
* I don't trust userland with this information to make the right choices,
  especially when faced with further levels of caches.

The main reason for people wanting the cache dimensions has been "so we
can select the optimal code for the CPU".  Given all the combinations
of caches out there, I've always said selecting code based on one level
of cache is totally insane, and userspace is better off doing some
performance measurement of its implementations and selecting the most
appropriate version.

There's many things that affect the performance of code paths with CPUs.
It's not just about cache line size, but instruction latencies, write
delays, branch prediction and so forth.  You can't _say_ "because this
CPU has a 32K L1 cache, if I optimise my code as X it'll perform
better everywhere with a 32K L1 cache than optimised Y."

Selecting code based on cache parameters is just wrong.

There may be cases where userspace would like to know the cache line
size, so it can appropriately align data structures - but that again
depends on what you're trying to achieve, and what if the L1 cache
line size is different from the L2 cache line size...

It's a minefield, one which IMHO userspace shouldn't be trusted with.
Userspace should assume the worst case cache line size seen in ARM
CPUs and be done with it.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  parent reply	other threads:[~2015-10-29 15: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 [this message]
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
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=20151029154346.GL8644@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --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).