On Fri, 2 Mar 2007, Mel Gorman wrote: > > I still think that the list based approach is sufficient for memory > > hotplug if one restricts the location of the unmovable MAX_ORDER chunks > > to not overlap the memory area where we would like to be able to remove > > memory. > > Yes, true. In the part where I bias placements of unmovable pages at > lower PFNs, additional steps would need to be taken. Specifically, the > lowest block MAX_ORDER_NR_PAGES used for movable pages would need to be > reclaimed for unmovable allocations.
I think sparsemem can provide some memory maps that show where there are section of memory that are hot pluggable. So the MAX_ORDER blocks need to be categorized as to whether they are in such a section or not. If you need another MAX_ORDER block for an unmovable type of allocation then make sure that it is not marked as hotpluggable by sparsemem. If we are in an emergency situation were we must use a MAX_ORDER block that is currently hotpluggable for unmovable allocations then we need to trigger something in sparsmem that disabled hotplug for that memory section. > It's simply more complex. I believe it's doable. The main plus going for > the zone is that it is a clearly understood concept and it gives hard > guarantees. And it gives the sysadmin headaches and increases management VM management overhead because we now have more bits in the page struct that tell us about the zone that the page belongs to. Another distinction to worry about in the VM. If the limit is set too high then we have memory that is actually movable but since its on the wrong side of the limit we cannot use it. If the limit is set too low then the systewm will crash. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
