Re: question on page-migration code

Marcelo Tosatti
2005-04-15T12:53:55Z

Hi Toshihiro,

On Fri, Apr 15, 2005 at 03:41:38PM +0900, IWAMOTO Toshihiro wrote:
> 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).

Ah, OK.

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

Right.

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

Yes, makes sense.

Question: Who is causing the writeouts here?

Is there memory pressure or is it pdflush?

Its not the migration code? (that would be a problem I think).