From: wenchao <wenchaolinux@gmail.com>
To: Mel Gorman <mgorman@suse.de>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hughd@google.com,
walken@google.com, viro@zeniv.linux.org.uk,
kirill.shutemov@linux.intel.com,
xiaoguangrong@linux.vnet.ibm.com, anthony@codemonkey.ws,
stefanha@gmail.com
Subject: Re: [RFC PATCH V1 0/6] mm: add a new option MREMAP_DUP to mmrep syscall
Date: Fri, 10 May 2013 10:28:46 +0800 [thread overview]
Message-ID: <518C5B5E.4010706@gmail.com> (raw)
In-Reply-To: <20130509141329.GC11497@suse.de>
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.
--
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>
next prev parent reply other threads:[~2013-05-10 2:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-09 9:50 [RFC PATCH V1 0/6] mm: add a new option MREMAP_DUP to mmrep syscall wenchaolinux
2013-05-09 9:50 ` [RFC PATCH V1 1/6] mm: add parameter remove_old in move_huge_pmd() wenchaolinux
2013-05-09 9:50 ` [RFC PATCH V1 2/6] mm : allow copy between different addresses for copy_one_pte() wenchaolinux
2013-05-09 9:50 ` [RFC PATCH V1 3/6] mm : export rss vec helper functions wenchaolinux
2013-05-09 9:50 ` [RFC PATCH V1 4/6] mm : export is_cow_mapping() wenchaolinux
2013-05-09 9:50 ` [RFC PATCH V1 5/6] mm : add parameter remove_old in move_page_tables wenchaolinux
2013-05-09 9:50 ` [RFC PATCH V1 6/6] mm : add new option MREMAP_DUP to mremap() syscall wenchaolinux
2013-05-09 14:13 ` [RFC PATCH V1 0/6] mm: add a new option MREMAP_DUP to mmrep syscall Mel Gorman
2013-05-10 2:28 ` wenchao [this message]
2013-05-10 5:11 ` Stefan Hajnoczi
2013-12-17 5:59 ` Xiao Guangrong
2013-12-30 20:23 ` Marcelo Tosatti
2013-12-31 12:06 ` Xiao Guangrong
2013-12-31 18:53 ` Marcelo Tosatti
2014-01-06 7:41 ` Xiao Guangrong
2013-05-10 9:22 ` Kirill A. Shutemov
2013-05-11 14:16 ` Pavel Emelyanov
2013-05-13 2:40 ` wenchao
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=518C5B5E.4010706@gmail.com \
--to=wenchaolinux@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=anthony@codemonkey.ws \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=stefanha@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=walken@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).