Re: question on page-migration code

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Wed, Apr 13, 2005 at 07:48:00PM +0900, Hirokazu Takahashi wrote:
> Hi,
> 
> > > If the method isn't implemented for the page, the migration code
> > > calls pageout() and try_to_release_page() to release page->private
> > > instead. 
> > > 
> > > Which filesystem are you using? I guess it might be XFS which
> > > doesn't have the method yet.
> > 
> > Can we more easily detect and work around this in the code, so that this
> > won't happen for more filesystems?
> 
> As Ray said, the following seems to be a straight approach.
> I haven't had any other ideas to work around it. 

>From my understanding there are two problems:

1) PG_private set on file pages whose filesystems do not implement 
->migrate_page() method.

Not much can be done about it, except implementing migrate_page() for all 
filesystems using page->private for uses other than buffer_head's.

BTW: only ext2/3 are implementing migrate_page(), all buffer_head 
based filesystems should do the same on a final version. 
Have you guys tried fs'es other than ext2/3? 

Dave, I dont understand what you mean with "workaround". The page is 
not migratable, thus the memory area which contains it can't 
be migrated either.

2) PG_dirty bit set on anonymous pages which have been migrated.

> ray> I guess it seems to me that if a page has pte dirty set, but doesn't have
> ray> PG_dirty set, then that state should be carried over to the newpage after
> ray> a migration, rather than sweeping the pte dirty bit into the PG_dirty bit.

The dirty bit is set by swap allocation and freeing code. 

> The implementation might be as follows:
>    - to make try_to_unmap_one() record dirty bit in anywhere
>      instead of calling set_page_dirty().
>    - to make touch_unmapped_address() call get_user_pages() with
>      the record of the dirty bit.

Quoting Ray:
"Checking /proc/vmstat/pgpgout appears to indicate that the pages I am
migrating are being swapped out when I see the migration slow down,
although something is fishy with pgpgout."

Anonymous pages seem to the problem Ray is seeing, except (1) which 
vanishes with ext2/ext3 as he reports.

Anon pages _should_ be removed from the swapcache at the end of 
generic_migrate_page (__remove_exclusive_swap_page()).

So, it does not matter if they have PG_dirty bit set, as long as
they are not swap-allocated (PageSwapCache).

Ray, please confirm that anon pages are removed from the swapcache after
being migrated (watching /proc/meminfo should do it).

One point is that if free memory is below the safe watermarks, the
system will vmscan, allocating swap & writing out, which is expected.

How much memory is free during said tests? 

> However, we have to remember that there must exit some race conditions.
> For example, it may fail to restore the dirty bit since the process
> address spaces might be deleted during the memory migration.
> This may occur as the process isn't suspended during the migration.

The PG_dirty bit is set, by the migration code, for anonymous pages only.

That said, I see no need to reset PG_dirty in case it was not set before
migration, as you propose.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>