linux-mips
[Top] [All Lists]

Re: What about...

To: Alan Cox <alan@lxorguk.ukuu.org.uk>, Greg Chesson <greg@xtp.engr.sgi.com>
Subject: Re: What about...
From: ralf@uni-koblenz.de
Date: Sat, 18 Jul 1998 03:37:59 +0200
Cc: wje@fir.engr.sgi.com, adevries@engsoc.carleton.ca, anubis@BanjaLuka.NET, linux@cthulhu.engr.sgi.com
In-reply-to: <m0yxF1A-000aOoC@the-village.bc.nu>; from Alan Cox on Fri, Jul 17, 1998 at 07:14:04PM +0100
References: <9807171047.ZM18720@xtp.engr.sgi.com> <m0yxF1A-000aOoC@the-village.bc.nu>
Sender: owner-linux@cthulhu.engr.sgi.com
On Fri, Jul 17, 1998 at 07:14:04PM +0100, Alan Cox wrote:

> > many "holes"...  The idea of a simple buddy-system allocator as is
> > ingrained in the Linux kernel falls apart completely in the face of
> > this kind of architecture.   I suppose you could run a copy of Linux
> > on every node, but I consider that an excuse rather than a solution.
> 
> Actually the Linux buddy stuff is quite happy with holes. Its still
> completely inappropriate. From the above I deduce we'd have to do
> mips64 before we even considerd it anyway

At least in Vger CVS we alredy have code to efficiently deal with
non-dense memory architectures with buddy.

I think the memory allocator design as presented by Rik van Riel looks as
if it is a good base to deal much more efficiently with such an
memory architecture.  And then there is Sct with his big iron experience
working on something better than the buddy system.

I completly agree that we first have to go to MIPS64 before we really
can attack big iron problems.  The current Linux/MIPS kernel design limits
the memory to the size of KSEG0 which is 512mb.  Putting Linux into a
64bit universe we'd extend that design limit to the size of XKSEG0, or
1TB for current silicon.

  Ralf

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