qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Juan Quintela <quintela@redhat.com>,
	Hugh Dickins <hughd@google.com>,
	qemu-devel@nongnu.org, linux-kernel@vger.kernel.org,
	Orit Wasserman <owasserm@redhat.com>,
	Mel Gorman <mgorman@suse.de>, Paolo Bonzini <pbonzini@redhat.com>,
	Isaku Yamahata <yamahata@valinux.co.jp>
Subject: Re: [Qemu-devel] [PATCH 0/4] madvise(MADV_USERFAULT) & sys_remap_anon_pages()
Date: Tue, 7 May 2013 14:19:54 +0200	[thread overview]
Message-ID: <20130507121954.GE12538@redhat.com> (raw)
In-Reply-To: <20130507113809.GB10720@hawk.usersys.redhat.com>

On Tue, May 07, 2013 at 01:38:10PM +0200, Andrew Jones wrote:
> What about instead of adding a new syscall (remap_anon_pages) to
> instead extend mremap with new flags giving it a strict mode?

I actually thought about this and it's a very interesting argument.

When I thought about it, I felt the problem was that we won't know
until we did some work (at least until reaching _each_ individual page
structure of every page mapped in the mremapped range) if we can avoid
the vma mangling or not. So then remap_anon_pages should be more
efficient because it will just error out if strict mode is not
possible, it won't need to search all page structures before it know
if it has to do the vma mangling or not.

It likely is simpler too than to try to teach mremap to do both things
after checking which one it can do.

Also, the same argument could be made about remap_file_pages too.

But it's still an interesting point, let's see what others thinks
about it.

      reply	other threads:[~2013-05-07 12:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-06 19:56 [Qemu-devel] [PATCH 0/4] madvise(MADV_USERFAULT) & sys_remap_anon_pages() Andrea Arcangeli
2013-05-06 19:56 ` [Qemu-devel] [PATCH 1/4] mm: madvise MADV_USERFAULT Andrea Arcangeli
2013-05-07 11:16   ` Andrew Jones
2013-05-07 11:34     ` Andrea Arcangeli
2013-05-06 19:56 ` [Qemu-devel] [PATCH 2/4] mm: rmap preparation for remap_anon_pages Andrea Arcangeli
2013-05-06 19:57 ` [Qemu-devel] [PATCH 3/4] mm: swp_entry_swapcount Andrea Arcangeli
2013-05-06 19:57 ` [Qemu-devel] [PATCH 4/4] mm: sys_remap_anon_pages Andrea Arcangeli
2013-05-06 20:01   ` Andrea Arcangeli
2013-05-07 10:07 ` [Qemu-devel] [PATCH 0/4] madvise(MADV_USERFAULT) & sys_remap_anon_pages() Isaku Yamahata
2013-05-07 12:09   ` Andrea Arcangeli
2013-05-07 11:38 ` Andrew Jones
2013-05-07 12:19   ` Andrea Arcangeli [this message]

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=20130507121954.GE12538@redhat.com \
    --to=aarcange@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=drjones@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=owasserm@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=yamahata@valinux.co.jp \
    /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).