All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@parallels.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux MM <linux-mm@kvack.org>, Matt Mackall <mpm@selenic.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Glauber Costa <glommer@parallels.com>,
	Matthew Wilcox <willy@linux.intel.com>
Subject: Re: [RFC PATCH 1/1] mm: Another attempt to monitor task's memory changes
Date: Tue, 09 Apr 2013 19:08:27 +0400	[thread overview]
Message-ID: <51642EEB.1010204@parallels.com> (raw)
In-Reply-To: <20130408153024.4edbcb491f18c948adbe9fe8@linux-foundation.org>

On 04/09/2013 02:30 AM, Andrew Morton wrote:
> On Fri, 05 Apr 2013 21:06:12 +0400 Pavel Emelyanov <xemul@parallels.com> wrote:
> 
>> Hello,
>>
>> This is another attempt (previous one was [1]) to implement support for 
>> memory snapshot for the the checkpoint-restore project (http://criu.org).
>> Let me remind what the issue is.
>>
>> << EOF
>> To create a dump of an application(s) we save all the information about it
>> to files, and the biggest part of such dump is the contents of tasks' memory.
>> However, there are usage scenarios where it's not required to get _all_ the
>> task memory while creating a dump. For example, when doing periodical dumps,
>> it's only required to take full memory dump only at the first step and then
>> take incremental changes of memory. Another example is live migration. We 
>> copy all the memory to the destination node without stopping all tasks, then
>> stop them, check for what pages has changed, dump it and the rest of the state,
>> then copy it to the destination node. This decreases freeze time significantly.
>>
>> That said, some help from kernel to watch how processes modify the contents
>> of their memory is required. Previous attempt used ftrace to inform userspace
>> about memory being written to. This one is different.
>>
>> EOF
> 
> Did you consider teaching the kernel to perform a strong hash on a
> page's contents so that userspace can do a before-and-after check to see
> if it changed?

I did (unless I misunderstood _your_ idea with hashes :( ), but judged, that
a single bit on a pte would be less cpu and memory consuming than calculating
and keeping 32/64 bits of hash value.


As far as all other comments are concerned -- thanks a LOT for the feedback!
I will address them all.


Thanks,
Pavel

--
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: Pavel Emelyanov <xemul@parallels.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linux MM <linux-mm@kvack.org>, Matt Mackall <mpm@selenic.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Glauber Costa <glommer@parallels.com>,
	Matthew Wilcox <willy@linux.intel.com>
Subject: Re: [RFC PATCH 1/1] mm: Another attempt to monitor task's memory changes
Date: Tue, 09 Apr 2013 19:08:27 +0400	[thread overview]
Message-ID: <51642EEB.1010204@parallels.com> (raw)
In-Reply-To: <20130408153024.4edbcb491f18c948adbe9fe8@linux-foundation.org>

On 04/09/2013 02:30 AM, Andrew Morton wrote:
> On Fri, 05 Apr 2013 21:06:12 +0400 Pavel Emelyanov <xemul@parallels.com> wrote:
> 
>> Hello,
>>
>> This is another attempt (previous one was [1]) to implement support for 
>> memory snapshot for the the checkpoint-restore project (http://criu.org).
>> Let me remind what the issue is.
>>
>> << EOF
>> To create a dump of an application(s) we save all the information about it
>> to files, and the biggest part of such dump is the contents of tasks' memory.
>> However, there are usage scenarios where it's not required to get _all_ the
>> task memory while creating a dump. For example, when doing periodical dumps,
>> it's only required to take full memory dump only at the first step and then
>> take incremental changes of memory. Another example is live migration. We 
>> copy all the memory to the destination node without stopping all tasks, then
>> stop them, check for what pages has changed, dump it and the rest of the state,
>> then copy it to the destination node. This decreases freeze time significantly.
>>
>> That said, some help from kernel to watch how processes modify the contents
>> of their memory is required. Previous attempt used ftrace to inform userspace
>> about memory being written to. This one is different.
>>
>> EOF
> 
> Did you consider teaching the kernel to perform a strong hash on a
> page's contents so that userspace can do a before-and-after check to see
> if it changed?

I did (unless I misunderstood _your_ idea with hashes :( ), but judged, that
a single bit on a pte would be less cpu and memory consuming than calculating
and keeping 32/64 bits of hash value.


As far as all other comments are concerned -- thanks a LOT for the feedback!
I will address them all.


Thanks,
Pavel

  reply	other threads:[~2013-04-09 15:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05 17:06 [RFC PATCH 1/1] mm: Another attempt to monitor task's memory changes Pavel Emelyanov
2013-04-05 17:06 ` Pavel Emelyanov
2013-04-08 22:30 ` Andrew Morton
2013-04-08 22:30   ` Andrew Morton
2013-04-09 15:08   ` Pavel Emelyanov [this message]
2013-04-09 15:08     ` Pavel Emelyanov
2013-04-08 23:10 ` KOSAKI Motohiro
2013-04-08 23:10   ` KOSAKI Motohiro
2013-04-09 14:52   ` Pavel Emelyanov
2013-04-09 14: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=51642EEB.1010204@parallels.com \
    --to=xemul@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=glommer@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpm@selenic.com \
    --cc=willy@linux.intel.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.