Re: question on page-migration code

Marcelo Tosatti
2005-04-20T18:16:18Z

Ray,

On Mon, Apr 18, 2005 at 09:46:03PM -0500, Ray Bryant wrote:
> Hirokazu et al,
>
> I'm sorry, I've been kind of out of the loop here since last Wenesday
> (that's the day I left Austin to fly to Melbourne, Australia which is
> where I am now, visiting the SGI lab in Melbourne).
>
> Nathan Scott (who works at SGI Melbourne) looked at the ext2/ext3
> migrate_page code and realized that basically the same implementation
> would work for xfs. So I now have a kernel that implements that
> function for xfs and, as you predicted, the "slow down" in the 2nd
> migration that I was seeing before has gone away. I'll add Nathan's
> patch to my manual page migration stuff in the next version (later
> this week, I hope).
>
> So I guess it doesn't matter to me at the moment whether or not
> the PG_dirty bit is set on the pages, except that I philosphically
> dislike the fact that migration changes the state of the page.
> I'm not sure it matters, but I would prefer it if this didn't
> happen. However, I'm not adamant about this, since what I really
> want to happen is to have a functioning manual page migration
> system call. It does seem to be a bother to have to add that
> migrate_page method to each file system, since in most cases
> the addition is going to look somewhat like it does for ext2/3.

One could create "block_migrate_page()" in fs/buffer.c so to void
migrate_page definition on each filesystem which uses buffer_head's.

But all address_space_operations need to be updated anyway.

> For xfs, Nathan did add an additional bit to make sure that
> xfs metadata pages were not considered migratable.
>
> WRT, Marcelo's question as to who is causing the page out I/O
> to occur during migration, let me go back and verify this is
> actually what is happening.
>
> Otherwise, is there a consensus about what to do about the
> PG_dirty bits being set on the migrated pages? As I read
> things Marcelo says it is not worth it, but others think
> that it should be fixed?

Dirty mmaped file pages will have their dirty tag migrated from
ptes to pages via unmapping (try_to_unmap), which causes
pdflush to sync these pages when their inodes get aged, as
Toshihiro notices.

I dislike the idea of "saving the dirty state to reinstantiate
it later", but, it seems its the only way of avoiding the dirty
mmaped file writeouts.