From: Rik van Riel <riel@redhat.com>
To: Nick Piggin <npiggin@suse.de>
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: Mon, 01 Feb 2010 10:55:35 -0500 [thread overview]
Message-ID: <4B66F977.5010708@redhat.com> (raw)
In-Reply-To: <20100201061532.GC9085@laptop>
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.
--
All rights reversed.
--
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:[~2010-02-01 15:57 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 [this message]
2010-02-02 6:44 ` Nick Piggin
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=4B66F977.5010708@redhat.com \
--to=riel@redhat.com \
--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=npiggin@suse.de \
/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).