Re: The performance and behaviour of the anti-fragmentation relatedpatches

[KAMEZAWA Hiroyuki]

On Fri, 2 Mar 2007 16:32:07 +0000
mel@xxxxxxxxx (Mel Gorman) wrote:

> The zone-based patches for memory partitioning should be providing what is
> required for memory hot-remove of an entire DIMM or bank of memory (PPC64
> also cares about removing smaller blocks of memory but zones are overkill
> there and anti-fragmentation on its own is good enough).  Pages hot-added
> to ZONE_MOVABLE will always be reclaimable or migratable in the case of
> mlock(). Kamezawa Hiroyuki has indicated that his hot-remove patches also
> do something like ZONE_MOVABLE. I would hope that his patches could be
> easily based on top of my memory partitioning set of patches. The markup
> of pages has been tested and the zone definitely works. I've added the
> kamezawa.hiroyu@xxxxxxxxxxxxxx to the cc list so he can comment :)

Thanks. As you wrote, I'm planning to write patch based on ZONE_MOVABLE.
I'm now using my own one just because I can't handle too many patches.
My version has a few just-for-cleanup patches. And it may be a bit different
from yours. I'll add cc to you when I post.
It's not ready to send yet...(found some panic at offlining memory ;)

> What I do not do in my patchset is hot-add to ZONE_MOVABLE because I couldn't
> be certain it's what the hotplug people wanted. They will of course need to
> hot-add to that zone if they want to be able to remove it later.
> 
I'm planing to make hot-added memory as ZONE_MOVABLE. I believe we can find and 
move movable pages in ZONE_NOT_MOVABLE to ZONE_MOVABLE.(or kswapd/pageout will
do this in slow way.) The reason is that my first purpose is removing hot-added-memory.

I think I can add knob to choose a zone for hot-added-memory but I won't do it
until someone wants it.

> For node-based memory hot-add and hot-remove, the node would consist of just
> one populated zone - ZONE_MOVABLE.
> 
yes.

Note:
We are considering to allocate well-known-structures like mem_map and pgdat
from hot-added memory. We can remove it when a node is unplugged.
But no plan/patches yet.


> For the removal of DIMMs, anti-fragmentation has something additional
> to offer. The later patches in the anti-fragmentation patchset bias the
> placement of unmovable pages towards the lower PFNs. It's not very strict
> about this because being strict would cost. A mechanism could be put in place
> that enforced the placement of unmovables pages at low PFNS. Due to the cost,
> it would need to be disabled by default and enabled on request. On the plus
> side, the cost would only be incurred when splitting a MAX_ORDER block of
> pages which is a rare event.

And kernel on VM, IBM's uses 16MB sparsemem for memory-hotplug, can get
enough benefit. While Xen's baloon driver can do memory-unplug, I heard
it causes memory fragmentation. anti-frag patch will help this.

-Kame

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/