> 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 :-) Actually what about that: LMB entries are linked-listed. The array is just storage for those entry "heads". The initial static array only needs to be big enough for very very early platform specific kernel bits and pieces, so it could even be sized by a Kconfig option. Or it could just use a klimit moving trick to pick up a page right after the BSS but that may need to be arch specific. lmb_init() queues all the entries from the initial array in a freelist lmb_alloc() and lmb_reserve() just pop entries from that freelist to populate the two main linked lists (memory and reserved). When something tries to dequeue up the last freelist entry, then under the hood, LMB uses it instead to allocate a new block of LMB entries that gets added to the freelist. We never free blocks of LMB entries. That way, we can fine tine the static array to be as small as we can realistically make it be, and we have no boundary limitations on the amount of entries in either the memory list or the reserved list. I'm a bit too flat out right now to write code, but if there's no objection, I might give that a go either later this week or next week, see if I can replace bootmem on powerpc. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
