From: Rob Landley <rob@landley.net>
To: linux-sh@vger.kernel.org
Subject: Re: Fixing SH cache assumptions
Date: Wed, 23 Mar 2016 05:08:51 +0000 [thread overview]
Message-ID: <56F224E3.9040406@landley.net> (raw)
In-Reply-To: <20160322211905.GA11781@brightrain.aerifal.cx>
On 03/22/2016 04:19 PM, Rich Felker wrote:
> Currently arch/sh has a hard-coded assumption that the cache is
> virtually indexed (and virtually tagged, from what I can tell), and
> thus needs to account for pages that may alias. While this is correct
> for SH3/4, it's wrong for anything NOMMU (since there are no virtual
> addresses, only physical) and the only reason SH2 works at all is
> because its small cache size (256 lines * 16 bytes per line) matches
> the page size, yielding an alias_mask of 0. If the cache were any
> larger (like it is on J2) then the alias avoidance logic would kick in
> and lead to calling kmap_coherent (which is BUG() on NOMMU) and
> possibly other incorrect or suboptimal behavior.
>
> I've avoided the issue so far on J2 simply by lying that the cache is
> small, but this needs a proper fix. It would be easy to just #ifndef
> out the logic that sets up alias_mask and shm_align_mask on NOMMU, but
> I think it would be better to somehow represent the cache indexing in
> the cache_info struct or elsewhere. In case the future J4 has a
> physically indexed cache (which is my hope), such an approach should
> naturally work for it with no further modifications.
Wikipedia[citation needed] is under the impression that physically
indexed caches are not a happy thing on systems with MMU:
https://en.wikipedia.org/wiki/CPU_cache#Address_translation
(I so want search anchors. Instead of #Address_translation, if I could
add $PIPT it could jump you right where you needed to go. But no,
mozilla never did that and chrome apparently hasn't thought of it.)
This sounds like something nommu systems do. Are any other nommu systems
currently device tree enabled? (Blackfish? Coldfire? Is any of the
Cortex-M stuff actually merged in-tree yet?)
> Any preferences for how I do this? Just add a type field to cache_info
> and make the default VIVT for existing models?
It sounds like a device tree issue. How would you represent it there?
> Rich
Rob
next prev parent reply other threads:[~2016-03-23 5:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 21:19 Fixing SH cache assumptions Rich Felker
2016-03-23 5:08 ` Rob Landley [this message]
2016-03-23 7:45 ` Geert Uytterhoeven
2016-03-23 16:41 ` Rich Felker
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=56F224E3.9040406@landley.net \
--to=rob@landley.net \
--cc=linux-sh@vger.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;
as well as URLs for NNTP newsgroup(s).