Generic DISCONTIGMEM Support on 32bit MIPS

Generic DISCONTIGMEM Support on 32bit MIPS

[Phil Thompson]

I'm working on a port of 32bit MIPS to a board with several large holes
in the memory map. So I need to re-implement paging_init() and
mem_init().

The first question is: has anybody already done this? Particularly as,
once you've identified where the holes are, the code isn't board
specific.

If not then I'll try to work out what needed from the corresponding
mips64 and ip27 code, but I'd appreciate any pointers.

Thanks,
Phil

Re: Generic DISCONTIGMEM Support on 32bit MIPS

[Ralf Baechle]

On Fri, Jan 25, 2002 at 04:10:50PM +0000, Phil Thompson wrote:

> I'm working on a port of 32bit MIPS to a board with several large holes
> in the memory map. So I need to re-implement paging_init() and
> mem_init().
> 
> The first question is: has anybody already done this? Particularly as,
> once you've identified where the holes are, the code isn't board
> specific.
> 
> If not then I'll try to work out what needed from the corresponding
> mips64 and ip27 code, but I'd appreciate any pointers.

Great, I was already planning to do this next.  Discontiguous memory is a
common problem on MIPS systems; it's almost standard for systems that
have more than 256mb of memory.

  Ralf

Re: Generic DISCONTIGMEM Support on 32bit MIPS

[Phil Thompson]

Ralf Baechle wrote:
> 
> On Fri, Jan 25, 2002 at 04:10:50PM +0000, Phil Thompson wrote:
> 
> > I'm working on a port of 32bit MIPS to a board with several large holes
> > in the memory map. So I need to re-implement paging_init() and
> > mem_init().
> >
> > The first question is: has anybody already done this? Particularly as,
> > once you've identified where the holes are, the code isn't board
> > specific.
> >
> > If not then I'll try to work out what needed from the corresponding
> > mips64 and ip27 code, but I'd appreciate any pointers.
> 
> Great, I was already planning to do this next.  Discontiguous memory is a
> common problem on MIPS systems; it's almost standard for systems that
> have more than 256mb of memory.

You may still be quicker as I'm starting from a position of almost
complete ignorance.

Phil

Re: Generic DISCONTIGMEM Support on 32bit MIPS

[Jason Gunthorpe]

On Fri, 25 Jan 2002, Phil Thompson wrote:

> The first question is: has anybody already done this? Particularly as,
> once you've identified where the holes are, the code isn't board
> specific.

Is this of any help?

http://kt.zork.net/kernel-traffic/kt20011112_141.html#6

William Irwin [*] announced:

A number of people have expressed a wish to replace the bitmap-based
bootmem allocator with one that tracks ranges explicitly. I have written
such a replacement in order to deal with some of the situations I have
encountered. 
[...]

Jason

Re: Generic DISCONTIGMEM Support on 32bit MIPS

[William Lee Irwin III]

On Fri, 25 Jan 2002, Phil Thompson wrote:
>> The first question is: has anybody already done this? Particularly as,
>> once you've identified where the holes are, the code isn't board
>> specific.

On Fri, Jan 25, 2002 at 02:20:33PM -0700, Jason Gunthorpe wrote:
> Is this of any help?
> http://kt.zork.net/kernel-traffic/kt20011112_141.html#6
> William Irwin [*] announced:
> A number of people have expressed a wish to replace the bitmap-based
> bootmem allocator with one that tracks ranges explicitly. I have written
> such a replacement in order to deal with some of the situations I have
> encountered. 
> [...]

I ran into some code acceptance issues in three places:
(1) I used trees
(2) I didn't go about changing the arch-specific code to
	actually simplify the calling sequence as it appeared
	in arch-specific code.
(3) it is a whole-hog rewrite of bootmem.c, which perhaps attracted
	flak from the original author

The last bits of this I released are in:
	ftp://ftp.kernel.org/pub/linux/kernel/people/wli/bootmem/

I'm not sure it addresses all the issues that arise here -- largely
it just avoids some code complexity in laying out the bootmem bitmaps.

DISCONTIGMEM as I understand it just minimally adjusts the core bootmem
so it can handle things at all, and then focuses on the actual hard
parts needed for things to work well on larger systems.

(Of course, that's an extremely vague description of the difference, but
I won't go about reciting featuresets aside from this high-level stuff.)

Cheers,
Bill