Re: The performance and behaviour of the anti-fragmentation related patches

Christoph Lameter
2007-03-02T17:48:21Z

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.