linux-mips
[Top] [All Lists]

Re: Highmem in architechtures with cache alias

To: Mikael Starvik <mikael.starvik@axis.com>
Subject: Re: Highmem in architechtures with cache alias
From: Ralf Baechle <ralf@linux-mips.org>
Date: Fri, 11 Feb 2011 00:23:40 +0100
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-reply-to: <4BEA3FF3CAA35E408EA55C7BE2E61D055C60823A4F@xmail3.se.axis.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4BEA3FF3CAA35E408EA55C7BE2E61D055C60823A4F@xmail3.se.axis.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Feb 07, 2011 at 10:02:34AM +0100, Mikael Starvik wrote:

> It is clearly stated in http://www.linux-mips.org/wiki/Highmem that the
> MIPS kernel can´t user highmem on machines with cache aliasing and I
> understand the reason. So, what is the solution here? Switch to 16k
> pages? Or are there other ways to get more memory on a machine with cache
> aliases?

This is an implementation restriction.  I did the original MIPS highmem
work in early 2002 for a company which didn't want to be the first through
the 64-bit minefield; I was using a Sibyte Swarm evaluation board back then
and its SB1 cores happen not to have aliases so I was able to take a few
short cuts.

For many years after this virtually everybody was wise enough to go for
64-bit hardware and kernel for large memory systems so interest in
removing this restriction only came up like last year.

16k pages are probably a good idea anyway; in most cases they provide a
significant performance boost.  Details depend on the exact workload.

However I should mention that the combination of page sizes other than 4k
with highmem also is untested afaics.

The solution for the alias problem is the right mix of cacheflushes at
the right places and a strategy to avoid aliases where possible - business
as usual.  ARM already supports highmem with aliases.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>