![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 12:14 [from the cache] ©2003-2008 | |||||||||||||