Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.cy

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2010-03-23 at 10:48 +0100, Ingo Molnar wrote:
> > yes. put them in kernel/early_res.c and move them to lmb.c if lmb
> gugs are 
> > happy with the change.
> 
> Yes, they seemed OK with changing it to accomodate x86, as long as
> current 
> behavior stays compatible and as long as the changes are
> squeaky-clean.
> 
> Both of which are highly reasonable expectations ;-)

Yup. As I said, tho, I'd also like a little better level of explanation
and documentation (and I know the existing LMB interfaces are -not-
documented, but let's not add more shall we ? :-)

> I think we want to work towards the end result where we dont have
> bootmem.c  anymore. I.e. a modern LMB architecture should generally
> not make use of bootmem at all.

bootmem has one advantage over LMB, I think, in that LMB has this
annoying static array of regions, which is prone to being either too big
(wasted space) or too small.

We might want to consider a slightly smarter approach there if we are
going to replace bootmem.

I though one possibility would be to have LMB regions become more lists
than arrays, so that the static storage only needs to cover as much as
is needed during really early boot (and we could probably still move the
BSS top point on some archs to dynamically make more ... actually we
could be smart arses and use LMB to allocate more LMB list heads if we
are reaching the table limit :-)

> We could do that switch on x86 straight away, and make
> CONFIG_NO_BOOTMEM a 
> default-y option, hm? We could also hide the interactivity behind 
> CONFIG_DEBUG_VM or so - and eliminate it altogether later on.
> 
> We should also switch around the flag and turn it into CONFIG_BOOTMEM.

Cheers,
Ben.

> Hm?
> 
>         Ingo
> 
>