Re: [PATCH] MAX_MP_BUSSES increase

[Andi Kleen]

On Thu, Dec 20, 2001 at 11:29:32PM +0100, James Cleverdon wrote:
> Thanks to all who replied.  My rationale for simply increasing the size of 
> static arrays was to have a minimum impact on 2.4, as well as to make 
> something that Cannot Fail(TM).  If you like, I could make one for 2.5 that 
> would do an initial scan of the MPS table, allocate the arrays using the 
> bootmem allocator, then go about its business as usual.  (Special offer for a 
> limited time only!  mpc_* array overflow checking added at NO EXTRA CHARGE!!  
> ;^)

Shouldn't be that hard. In the worst case I can do it, but I don't have
hardware to test it properly. 

> 
> The catch with bootmem allocation is that it only allocates in pages (unless 
> wli's new bootmem allocator is adopted).  So, expect some extra memory to be 
> lost to internal fragmentation anyway.

I don't think that's true, unless I'm misreading the code in 
__alloc_bootmem_core badly. It may not be the most fragmentation avoiding 
allocator in the world, but for linear allocations with no frees it shouldn't
waste space. 

> Another suggestion through private mail was to make MAX_MP_BUSSES a tunable 
> config parameter.  I didn't know about that.  Early boot stuff should work 
> without fuss, not rely on config tweaks.  At the very least, I'd have to add 
> array overflow checking, because this crashes before the console is opened or 
> kdb is initialized.  Silent crashes like that are bad news.

I agree that it shouldn't be tunable. 

-Andi
-- 
Life would be so much easier if we could just look at the source code.