All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Pavel Emelyanov <xemul@parallels.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Matt Mackall <mpm@selenic.com>,
	Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH] mm: Save soft-dirty bits on swapped pages
Date: Wed, 24 Jul 2013 22:15:16 +0400	[thread overview]
Message-ID: <20130724181516.GI8508@moon> (raw)
In-Reply-To: <CALCETrV5MD1qCQsyz4=t+QW1BJuTBYainewzDfEaXW12S91K=A@mail.gmail.com>

On Wed, Jul 24, 2013 at 10:42:24AM -0700, Andy Lutomirski wrote:
> >
> > Lets just be clear about the problem first: the vmscan pass referred to
> > above happens only on clean pages, so the soft dirty bit could only be
> > set if the page was previously dirty and got written back.  Now it's an
> > exercise for the reader whether we want to reinstantiate a cleaned
> > evicted page for the purpose of doing an iterative migration or whether
> > we want to flip the page in the migrated entity to be evicted (so if it
> > gets referred to, it pulls in an up to date copy) ... assuming the
> > backing file also gets transferred, of course.

Good question! I rather forward it to Pavel as an author for soft dirty
bit feature. Pavel?

> I think I understand your distinction.  Nonetheless, given the loss of
> the soft-dirty bit, the migration tool could fail to notice that the
> pages was dirtied and subsequently cleaned and evicted.  I'm
> unconvinced that doing this on a per-PTE basis is the right way,
> though.

I fear for tracking soft-dirty-bit for swapped entries we sinply have
no other place than pte (still i'm quite open for ideas, maybe there
are a better way which I've missed).

> I've long wanted a feature to efficiently see what changed on a
> filesystem by comparing, say, a hash tree.  NTFS can do this (sort
> of), but I don't think that anything else can.  I think that btrfs
> should be able to, but there's no API that I've ever seen.

--
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:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Pavel Emelyanov <xemul@parallels.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Matt Mackall <mpm@selenic.com>,
	Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH] mm: Save soft-dirty bits on swapped pages
Date: Wed, 24 Jul 2013 22:15:16 +0400	[thread overview]
Message-ID: <20130724181516.GI8508@moon> (raw)
In-Reply-To: <CALCETrV5MD1qCQsyz4=t+QW1BJuTBYainewzDfEaXW12S91K=A@mail.gmail.com>

On Wed, Jul 24, 2013 at 10:42:24AM -0700, Andy Lutomirski wrote:
> >
> > Lets just be clear about the problem first: the vmscan pass referred to
> > above happens only on clean pages, so the soft dirty bit could only be
> > set if the page was previously dirty and got written back.  Now it's an
> > exercise for the reader whether we want to reinstantiate a cleaned
> > evicted page for the purpose of doing an iterative migration or whether
> > we want to flip the page in the migrated entity to be evicted (so if it
> > gets referred to, it pulls in an up to date copy) ... assuming the
> > backing file also gets transferred, of course.

Good question! I rather forward it to Pavel as an author for soft dirty
bit feature. Pavel?

> I think I understand your distinction.  Nonetheless, given the loss of
> the soft-dirty bit, the migration tool could fail to notice that the
> pages was dirtied and subsequently cleaned and evicted.  I'm
> unconvinced that doing this on a per-PTE basis is the right way,
> though.

I fear for tracking soft-dirty-bit for swapped entries we sinply have
no other place than pte (still i'm quite open for ideas, maybe there
are a better way which I've missed).

> I've long wanted a feature to efficiently see what changed on a
> filesystem by comparing, say, a hash tree.  NTFS can do this (sort
> of), but I don't think that anything else can.  I think that btrfs
> should be able to, but there's no API that I've ever seen.

  reply	other threads:[~2013-07-24 18:15 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-24 16:08 [PATCH] mm: Save soft-dirty bits on swapped pages Cyrill Gorcunov
2013-07-24 16:08 ` Cyrill Gorcunov
2013-07-24 16:23 ` Andy Lutomirski
2013-07-24 16:23   ` Andy Lutomirski
2013-07-24 16:37   ` Cyrill Gorcunov
2013-07-24 16:37     ` Cyrill Gorcunov
2013-07-24 17:06     ` Andy Lutomirski
2013-07-24 17:06       ` Andy Lutomirski
2013-07-24 17:17       ` Cyrill Gorcunov
2013-07-24 17:17         ` Cyrill Gorcunov
2013-07-24 17:36         ` James Bottomley
2013-07-24 17:36           ` James Bottomley
2013-07-24 17:42           ` Andy Lutomirski
2013-07-24 17:42             ` Andy Lutomirski
2013-07-24 18:15             ` Cyrill Gorcunov [this message]
2013-07-24 18:15               ` Cyrill Gorcunov
2013-07-24 18:21               ` Andy Lutomirski
2013-07-24 18:21                 ` Andy Lutomirski
2013-07-24 18:52                 ` Cyrill Gorcunov
2013-07-24 18:52                   ` Cyrill Gorcunov
2013-07-24 18:55                   ` Pavel Emelyanov
2013-07-24 18:55                     ` Pavel Emelyanov
2013-07-24 19:04                     ` Cyrill Gorcunov
2013-07-24 19:04                       ` Cyrill Gorcunov
2013-07-24 19:18                       ` Cyrill Gorcunov
2013-07-24 19:18                         ` Cyrill Gorcunov
2013-07-24 19:40                       ` Andy Lutomirski
2013-07-24 19:40                         ` Andy Lutomirski
2013-07-25  7:07                         ` Cyrill Gorcunov
2013-07-25  7:07                           ` Cyrill Gorcunov
2013-07-25  7:29                         ` Pavel Emelyanov
2013-07-25  7:29                           ` Pavel Emelyanov
2013-07-25  8:26                           ` Hush Bensen
2013-07-25  8:26                             ` Hush Bensen
2013-07-25  8:43                             ` Pavel Emelyanov
2013-07-25  8:43                               ` Pavel Emelyanov
2013-07-25 16:02                           ` Andy Lutomirski
2013-07-25 16:02                             ` Andy Lutomirski
2013-07-24 18:52   ` Pavel Emelyanov
2013-07-24 18:52     ` Pavel Emelyanov
2013-07-24 18:52 ` Pavel Emelyanov
2013-07-24 18:52   ` Pavel Emelyanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130724181516.GI8508@moon \
    --to=gorcunov@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=kosaki.motohiro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=mpm@selenic.com \
    --cc=mtosatti@redhat.com \
    --cc=sfr@canb.auug.org.au \
    --cc=xemul@parallels.com \
    --cc=xiaoguangrong@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.