On Mon, 2010-03-29 at 23:22 +1100, Michael Ellerman wrote: > ^ This is (sort of) what lmb.rmo_size represents. So maybe instead of > adding this function, we could just say that the arch code needs to set > rmo_size up with an appropriate value, and then use that below. Though > maybe that's conflating things. Well... not quite. The RMO (which really is the RMA, historical misnaming) is the region of memory we can access very early during boot (in real mode on ppc64 but I plan to use it to represent the boot-time fixed mapping on ppc32 at some stage). It's not strictly equivalent to max lowmem. However, on ppc64, it happens to be the size of the first added LMB entry/ In any case, the LMBs should really not care. They allocate where you tell them to. IE. That stuff is arch specific enough that I suspect we should just move it out, while the concept of max_lowmem is common enough (at least for 32-bit archs) that I'm happy to have some provisions for it inside the LMB core. Maybe what we need is an arch call to set the allocation "limit". It could be set in stages during boot. To the initial mapped memory (bolted TLB) on ppc32 very early, and then pushed up to max_low_pfn as soon as the full MMU setup is done for example. IE. All we need is an lmb_set_alloc_limit() called by the arch in the right spots, that defines the default allocation limit for lmb_alloc() though of course lmb_alloc_base() can be used by callers to enforce explicit limits. 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