Messages in this thread | | | Date | Wed, 02 Nov 2005 22:08:39 +0900 (JST) | Subject | Re: [PATCH 0/5] Swap Migration V5: Overview | From | Hirokazu Takahashi <> |
| |
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/
| |