Re: question on page-migration code

IWAMOTO Toshihiro
2005-04-15T06:41:38Z

At Thu, 14 Apr 2005 12:57:34 -0300,
Marcelo Tosatti wrote:
>
> On Wed, Apr 13, 2005 at 07:48:00PM +0900, Hirokazu Takahashi wrote:

> 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.

I think Ray is using the word "swap" to mean "page out" and anonymous
pages are irrelevant here, judging from his another mail (quoted below).

At Tue, 12 Apr 2005 00:43:42 -0500,
Ray Bryant wrote:
: BTW, the program that I am testing creates a relatively large mapped file,
: and, as you guessed, this file is backed by XFS. Programs that just use
: large amounts of anonymous storage are not effected by this problem, I
: would imagine.

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

If there are enough RAM, mmaped dirty pages shouldn't be written back.
However, memory migration triggers writebacks.

> > 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.

If a file page is mmaped and its PTE is dirty, the page gets PG_dirty
bit when it is unmapped.

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

I think PG_dirty should be reset, as the side effect is probably
unacceptable for Ray's application. It would be a bit more
complicated than just changing page and PTE bits, but I think it's
doable.

--
IWAMOTO Toshihiro