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/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:23 EST