From: Nick Piggin <npiggin@suse.de>
To: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
lwoodman@redhat.com, Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
aarcange@redhat.com
Subject: Re: [PATCH -mm] remove VM_LOCK_RMAP code
Date: Tue, 2 Feb 2010 17:44:09 +1100 [thread overview]
Message-ID: <20100202064409.GC6175@laptop> (raw)
In-Reply-To: <4B66F977.5010708@redhat.com>
On Mon, Feb 01, 2010 at 10:55:35AM -0500, Rik van Riel wrote:
> On 02/01/2010 01:15 AM, Nick Piggin wrote:
> >On Fri, Jan 29, 2010 at 07:34:10PM -0500, Rik van Riel wrote:
> >>When a VMA is in an inconsistent state during setup or teardown, the
> >>worst that can happen is that the rmap code will not be able to find
> >>the page.
> >
> >OK, but you missed the interesting thing, which is to explain why
> >that worst case is not a problem.
> >
> >rmap of course is not just used for reclaim but also invalidations
> >from mappings, and those guys definitely need to know that all
> >page table entries have been handled by the time they return.
>
> This is not a problem, because the mapping is in the process
> of being torn down (PTEs just got invalidated by munmap), or
> set up (no PTEs have been instantiated yet).
>
> The third case is split_vma, where we can have one VMA in an
> inconsistent state (rmap cannot find the PTEs), while the
> other VMA is still in its original state (rmap finds the PTEs
> through that VMA).
>
> That is what makes this safe.
OK, that sounds fine then. Your changelog was just a bit strange
because you said it would not be able to find the page, which
didn't really make sense.
--
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>
prev parent reply other threads:[~2010-02-02 6:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-28 5:20 [PATCH -mm] change anon_vma linking to fix multi-process server scalability issue Rik van Riel
2010-01-28 6:43 ` [PATCH -mm] rmap: remove obsolete check from __page_check_anon_rmap Rik van Riel
2010-02-01 15:26 ` Minchan Kim
2010-01-28 6:43 ` [PATCH -mm] rmap: move exclusively owned pages to own anon_vma in do_wp_page Rik van Riel
2010-02-01 15:25 ` Minchan Kim
2010-02-01 16:33 ` Rik van Riel
2010-01-28 16:37 ` [PATCH -mm] change anon_vma linking to fix multi-process server scalability issue Minchan Kim
2010-01-28 17:24 ` Rik van Riel
2010-01-29 0:55 ` Minchan Kim
2010-01-29 1:18 ` Rik van Riel
2010-01-29 23:14 ` Andrew Morton
2010-01-29 23:57 ` Rik van Riel
2010-01-30 0:22 ` [PATCH -mm] further cleanups to " Rik van Riel
2010-01-30 0:34 ` [PATCH -mm] remove VM_LOCK_RMAP code Rik van Riel
2010-02-01 6:15 ` Nick Piggin
2010-02-01 15:55 ` Rik van Riel
2010-02-02 6:44 ` Nick Piggin [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=20100202064409.GC6175@laptop \
--to=npiggin@suse.de \
--cc=Lee.Schermerhorn@hp.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lwoodman@redhat.com \
--cc=riel@redhat.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).