Re: What about...

[ralf@uni-koblenz.de]

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