linux-mips
[Top] [All Lists]

Re: MIPS 64?

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: MIPS 64?
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Sun, 19 May 2002 12:41:03 -0700
Cc: Jun Sun <jsun@mvista.com>, Daniel Jacobowitz <dan@debian.org>, Matthew Dharm <mdharm@momenco.com>, Linux-MIPS <linux-mips@oss.sgi.com>
In-reply-to: <007a01c1fca9$86e14f70$10eca8c0@grendel>; from kevink@mips.com on Thu, May 16, 2002 at 09:15:40AM +0200
References: <NEBBLJGMNKKEEMNLHGAIOEPPCGAA.mdharm@momenco.com> <20020515214818.GA1991@nevyn.them.org> <3CE2DA46.3070402@mvista.com> <007a01c1fca9$86e14f70$10eca8c0@grendel>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5.1i
On Thu, May 16, 2002 at 09:15:40AM +0200, Kevin D. Kissell wrote:

> Is this to say that Linux cannot function unless all physical memory
> on the system is mapped at all times into kernel space?  I would
> have thought that (a) all that really needs to be mapped is all
> memory used by the kernel itself, plus that of the currently active
> process (which is mapped in the 2GB kuseg), and that (b) one 
> could anyway manage kseg2 or 3 dynamically to provide a window 
> into a larger physical memory, and that this window could be
> used for any functions that need to do arbitrary phys-to-phys
> copies.

Highmem is your dynamic 4MB window into all memory that's not low memory.
KSEG2/3 are currently mostly reserved for vmalloc / ioremap and these
4MB of highmem mapping space - a usage that's certainly wasteful.

As opposed to that all the permanently mapped kernel memory in Linux is
called lowmem.

> I'm not sure what people's definition of a "64-bit kernel"
> is around here, but to me, that's a kernel which supports
> 64-bit virtual addressing and 64-bit registers.  It strikes
> me as being rather foolish to impose the overhead of all
> that on people whose only real requirement is 2G of RAM
> on a 32-bit CPU.  Particularly when many of the new
> MIPS parts that could plausibly be connected to 2GB
> RAM arrays, such as the Alchemy/AMD and MIPS 4K
> parts, don't support 64-bit operation.  So running away
> from the problem isn't really an option.

Highmem doesn't come without a price either - in particular processes doing
heavy I/O will possibly as much as 40% performance penalty (numbers from
Intel systems) and for sanity's sake - 64-bit is keeping people from going
nuts :)

A solution that will use most of KSEG2/3 for mapping more lowmemory is in
the works but it turned out to be drastically more complex that originally
thought so will still take a bit.

  Ralf

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