Re: [PATCH] MAX_MP_BUSSES increase

Andi Kleen (ak@muc.de)
Thu, 20 Dec 2001 23:56:48 +0100


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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/