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

[Hirokazu Takahashi <taka@valinux.co.jp>]

Hi Christoph,

The page migration code is waiting for something appearing to
use it but memory hotremove. I thought it would be memory
defragmentation or process migration.

> >> > > > Do you think the features which these patches add should be Kconfigurable?
> >> 
> >> This code looks no help for hot-remove. It seems able to handle only
> >> pages easily to migrate, while hot-remove has to guarantee all pages
> >> can be migrated.
> >
> >Right.
> >
> >> Hi Christoph, sorry I've been off from lhms for long time.
> >> 
> >> Shall I port the generic memory migration code for hot-remove to -mm tree
> >> directly, and add some new interface like migrate_page_to(struct page *from,
> >> struct page *to) so this may probably fit for your purpose.
> >> 
> >> The code is still in Dave's mhp1 tree waiting for being merged to -mm tree.
> >> The port will be easy because the migration code is independent to the
> >> memory hotplug code. The core code isn't so big.
> >
> >Please follow the discussion on lhms-devel. I am trying to bring these two 
> >things together.
> 
> I've read the archive of lhms-devel.
> You're going to take in most of the original migration code
> except for some tricks to migrate pages which are hard to move.
> I think this is what you said the complexity, which you
> want to remove forever.

If you don't like the code is devided into a lot of small pieces,
I can merge their patches into several patches.

> I have to explain that this complexity came from making the code
> guarantee to be able to migrate any pages. So the code is designed:
>   - to migrate heavily accessed pages.
>   - to migrate pages without backing-store.
>   - to migrate pages without I/O's.
>   - to migrate pages of which status may be changed during the migration
>     correctly.
> 
> This have to be implemented if the hotplug memory use it.
> It seems to become a reinvention of the wheel to me.
> 
> It's easy to add a new interface to the code for memory policy aware
> migration. It will be wonderful doing process migration prior to
> planed hotremove momory. This decision should be done out of kernel.

If you really want to skip the complex part, I can easily add a non-wait
mode to the migration code. 

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