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

[Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>]

CCed KVM guys.

On 05/10/2013 01:11 PM, Stefan Hajnoczi wrote:
> On Fri, May 10, 2013 at 4:28 AM, wenchao <wenchaolinux@gmail.com> 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.
>>
>>   To avoid complex communication for data control, and file content
>> protecting, So let parent instead of child handling the data with
>> a pipe, but this brings additional copy(). I think an explicit API
>> cow mapping an memory region inside one process, could avoid it,
>> and faster and cow less pages, also make user space code nicer.
> 
> A new Linux-specific API is not portable and not available on existing
> hosts.  Since QEMU supports non-Linux host operating systems the
> fork() approach is preferable.
> 
> If you're worried about the memory copy - which should be benchmarked
> - then vmsplice(2) can be used in the child process and splice(2) can
> be used in the parent.  It probably doesn't help though since QEMU
> scans RAM pages to find all-zero pages before sending them over the
> socket, and at that point the memory copy might not make much
> difference.
> 
> Perhaps other applications can use this new flag better, but for QEMU
> I think fork()'s portability is more important than the convenience of
> accessing the CoW pages in the same process.

Yup, I agree with you that the new syscall sometimes is not a good solution.

Currently, we're working on live-update[1] that will be enabled on Qemu firstly,
this feature let the guest run on the new Qemu binary smoothly without
restart, it's good for us to do security-update.

In this case, we need to move the guest memory on old qemu instance to the
new one, fork() can not help because we need to exec() a new instance, after
that all memory mapping will be destroyed.

We tried to enable SPLICE_F_MOVE[2] for vmsplice() to move the memory without
memory-copy but the performance isn't so good as we expected: it's due to
some limitations: the page-size, lock, message-size limitation on pipe, etc.
Of course, we will continue to improve this, but wenchao's patch seems a new
direction for us.

To coordinate with your fork() approach, maybe we can introduce a new flag
for VMA, something like: VM_KEEP_ONEXEC, to tell exec() to do not destroy
this VMA. How about this or you guy have new idea? Really appreciate for your
suggestion.

[1] http://marc.info/?l=qemu-devel&m=138597598700844&w=2
[2] https://lkml.org/lkml/2013/10/25/285


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