Re: question on page-migration code

Marcelo Tosatti
2005-04-14T15:57:34Z

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.