Re: [RFC PATCH V1 0/6] mm: add a new option MREMAP_DUP to mmrep syscall

[Pavel Emelyanov <xemul@parallels.com>]

On 05/10/2013 01:22 PM, Kirill A. Shutemov wrote:
> wenchao wrote:
>> ao? 2013-5-9 22:13, Mel Gorman a??e??:
>>> On Thu, May 09, 2013 at 05:50:05PM +0800, wenchaolinux@gmail.com wrote:
>>>> From: Wenchao Xia <wenchaolinux@gmail.com>
>>>>
>>>>    This serial try to enable mremap syscall to cow some private memory region,
>>>> just like what fork() did. As a result, user space application would got a
>>>> mirror of those region, and it can be used as a snapshot for further processing.
>>>>
>>>
>>> What not just fork()? Even if the application was threaded it should be
>>> managable to handle fork just for processing the private memory region
>>> in question. I'm having trouble figuring out what sort of application
>>> would require an interface like this.
>>>
>>    It have some troubles: parent - child communication, sometimes
>> page copy.
>>    I'd like to snapshot qemu guest's RAM, currently solution is:
>> 1) fork()
>> 2) pipe guest RAM data from child to parent.
>> 3) parent write down the contents.
> 
> CC Pavel

Thank you!

> I wounder if you can reuse the CRIU approach for memory snapshoting.

I doubt it. First of all, we need to have task's memory in existing external process
which is not its child. With MREMAP_DUP we can't have this. And the most important
thing is that we don't need pages duplication on modification. It's the waste of
memory for our case. We just need to know the fact that the page has changed.

Wenchao, why can't you use existing KVM dirty-tracking for making mem snapshot? As
per my understanding of how KVM MMU works you can

1 turn dirty track on
2 read pages from their original places
3 pick dirty bitmap and read changed pages several times
4 freeze guest
5 repeat step 3
6 release guest

Does it work for you?

This is very very similar to how we do mem snapshot with CRIU (dirty tracking is the
soft-dirty patches from the link Kirill provided).

> http://thread.gmane.org/gmane.linux.kernel/1483158/
> 


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>