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.