linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: gilles.chanteperdrix@xenomai.org (Gilles Chanteperdrix)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM caches variants.
Date: Tue, 23 Mar 2010 13:39:14 +0100	[thread overview]
Message-ID: <4BA8B672.7030508@xenomai.org> (raw)


Hi,

I am trying to have a better understanding of the issues with the
various types of caches used on ARM, and I came to a question I feel is
really stupid, but can not find the answer myself.

As I understood, the VIVT cache has the following issues:
- issue #1; two processes may use the same virtual address for different
physical addresses, but will share the same cache line and see memory
corruption if no precaution is taken;
- issue #2; two processes may use different virtual addresses for the
same physical address (shared mapping), but will use different cache
lines, causing all sorts of incoherence if no precaution is taken;
- issue #3; the same process may use different virtual addresses for the
same physical address (same shared mapping mapped several time in the
same process virtual memory), basically almost the same issue as issue #2.

The Linux kernel, solves issue #1 and #2 by flushing the cache at every
context switch, and issue #3 by remapping the multiply mapped shared
mapping in "uncacheable, buffered only" mode if write buffer is
sufficiently well behaved, or "uncacheable, unbuffered" mode if write
buffer is buggy.

Now, if we look at VIPT, aliasing caches:
- the physical tagging solves issue #1 automatically,
- the cache colouring technique used in arch_get_unmapped_area solves
issue #2 and #3 by ensuring that the areas using the same physical
address will end up using the same cache lines, and avoid aliases "by
construction".

VIPT non-aliasing caches have none of the three issues.

First question: did I get it right?
Second question: do issue #1, #2 and #3 have official non-ambiguous names?
Now, the stupid question: why not using the cache colouring technique
used for VIPT caches to solve issue #3 with VIVT caches?

I have thought about several answers:
- there is a technical reason which will make the cache colouring
technique fail with VIVT;
- the reason is purely historical, the two solutions were implemented at
different times;
- the issue #3 is a corner case and the cache colouring technique
induces a potential waste of virtual address space, so the trade off is
not interesting.

Thanks in advance for your answer.

-- 
					    Gilles.

             reply	other threads:[~2010-03-23 12:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-23 12:39 Gilles Chanteperdrix [this message]
2010-03-23 12:53 ` ARM caches variants Catalin Marinas
2010-03-23 13:15   ` Gilles Chanteperdrix
2010-03-23 13:42     ` Catalin Marinas
2010-03-23 13:59       ` Gilles Chanteperdrix
2010-03-23 14:33         ` Catalin Marinas
2010-03-23 14:39           ` Gilles Chanteperdrix
2010-03-23 14:46             ` Catalin Marinas
2010-03-23 14:47               ` Catalin Marinas
2010-03-23 14:49               ` Gilles Chanteperdrix
2010-03-23 23:39               ` Jamie Lokier
2010-03-24  9:33                 ` Catalin Marinas
2010-03-23 23:49       ` Jamie Lokier
2010-03-24  9:42         ` Catalin Marinas
2010-03-26  5:45           ` Jamie Lokier
2010-03-26 13:23             ` Catalin Marinas

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=4BA8B672.7030508@xenomai.org \
    --to=gilles.chanteperdrix@xenomai.org \
    --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).