Re: [PATCH 0/5] Swap Migration V5: Overview

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

Andrew Morton wrote:
> Christoph Lameter <clameter@sgi.com> wrote:
> 
>>This is a patchset intended to introduce page migration into the kernel
>> through a simple implementation of swap based page migration.
>> The aim is to be minimally intrusive in order to have some hopes for inclusion
>> into 2.6.15. A separate direct page migration patch is being developed that
>> applies on top of this patch. The direct migration patch is being discussed on
>> <lhms-devel@lists.sourceforge.net>.
> 
> 
> I remain concerned that it hasn't been demonstrated that the infrastructure
> which this patch provides will be adequate for all future applications -
> especially memory hot-remove.
>
 > So I'll queue this up for -mm, but I think we need to see an entire
 > hot-remove implementation based on this, and have all the interested
 > parties signed up to it before we can start moving the infrastructure into
 > mainline.
 >

It looks Christoph didn't use (direct)memory migration core in this set,
so memory-hotremove will not be affected by this.

At the first look, memory hotplugger will just replace swap_page()
with migrate_onepage().

Comparing swap-based migration and memory hotremove, memory hotremove
has to support wider kinds of pages other than anon, file-cache
swap-cache, mlocked() page used by direct I/O, HugeTLB pages and achieve
close to 100% guaranntee. Ignoring the fact migration and hotremove will
share the code, what they have to do is very different.

swap-based approach looks just intend to do process migration and
it itself looks not bad.

I think your point is that hotremove and migration will share some amounts of codes.
We are now discussing *direct* page migration and will share codes for anon pages.
It is being discussed in -lhms. We'd like to create good one.

Thanks,
-- KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>