linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@qumranet.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Robin Holt <holt@sgi.com>, Avi Kivity <avi@qumranet.com>,
	Izik Eidus <izike@qumranet.com>,
	kvm-devel@lists.sourceforge.net,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	steiner@sgi.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, daniel.blueman@quadrics.com
Subject: Re: [PATCH] mmu notifiers #v5
Date: Fri, 1 Feb 2008 13:00:28 +0100	[thread overview]
Message-ID: <20080201120028.GW7185@v2.random> (raw)
In-Reply-To: <Pine.LNX.4.64.0801311733140.24297@schroedinger.engr.sgi.com>

On Thu, Jan 31, 2008 at 05:37:21PM -0800, Christoph Lameter wrote:
> On Fri, 1 Feb 2008, Andrea Arcangeli wrote:
> 
> > I appreciate the review! I hope my entirely bug free and
> > strightforward #v5 will strongly increase the probability of getting
> > this in sooner than later. If something else it shows the approach I
> > prefer to cover GRU/KVM 100%, leaving the overkill mutex locking
> > requirements only to the mmu notifier users that can't deal with the
> > scalar and finegrined and already-taken/trashed PT lock.
> 
> Mutex locking? Could you be more specific?

Robin understanding was correct on this point. Also I think if you add
start,end to range_end (like suggested a few times by me and once
by Robin) I may get away without a lock thanks to the page pin. That's
one strong reason why start,end are needed in range_end.

The only one that will definitely be forced to add a new lock around
follow_page, in addition to the very _scalable_ PT lock, is GRU.

> I hope you will continue to do reviews of the other mmu notifier patchset?

Sure. I will also create a new KVM patch to plug on top of your
versions (I already did for V2/V3 even if it never worked, but that
might have a build problem, see kvm-devel for details). To be clear,
as long as anything is merged that avoids me to use kprobes to make
KVM swap work, I'm satisfied. I thought my approach had several
advantages in simplicity, and being more obviously safe (in not
relaying entirely on the page pin and creating a window of time where
the linux pte writes to a page and the sptes writes to another one,
remember populate_range), and it avoids introducing external locks in
the GRU follow_page path. My approach was supposed to be in addition
of the range_start/end needed by xpmem that can't possibly take
advanage of the scalar PT lock and it definitely requires external
lock to serialize xpmem fault against linux pagefault (not the case
for GRU/KVM).

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

      parent reply	other threads:[~2008-02-01 12:00 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-31  4:57 [patch 0/3] [RFC] MMU Notifiers V4 Christoph Lameter
2008-01-31  4:57 ` [patch 1/3] mmu_notifier: Core code Christoph Lameter
2008-02-01  1:56   ` Jack Steiner
2008-02-01  2:24     ` Robin Holt
2008-02-01  2:37       ` Jack Steiner
2008-02-01  2:39         ` Christoph Lameter
2008-02-01  2:31   ` Robin Holt
2008-02-01  2:39     ` Christoph Lameter
2008-02-01  2:47       ` Robin Holt
2008-02-01  3:01         ` Christoph Lameter
2008-02-01  3:01       ` Jack Steiner
2008-02-01  3:03         ` Christoph Lameter
2008-02-01  3:52   ` Robin Holt
2008-02-01  3:58     ` Christoph Lameter
2008-02-01  4:15       ` Robin Holt
2008-02-03  1:33       ` Andrea Arcangeli
2008-02-04 19:13         ` Christoph Lameter
2008-01-31  4:57 ` [patch 2/3] mmu_notifier: Callbacks to invalidate address ranges Christoph Lameter
2008-01-31 12:31   ` Andrea Arcangeli
2008-01-31 20:07     ` Christoph Lameter
2008-01-31 22:01     ` mmu_notifier: close hole in fork Christoph Lameter
2008-01-31 22:16       ` mmu_notifier: reduce size of mm_struct if !CONFIG_MMU_NOTIFIER Christoph Lameter
2008-01-31 22:21       ` mmu_notifier: Move mmu_notifier_release up to get rid of the invalidat_all() callback Christoph Lameter
2008-02-01  0:13         ` Andrea Arcangeli
2008-02-01  1:52           ` Christoph Lameter
2008-02-01  1:57           ` mmu_notifier: invalidate_range for move_page_tables Christoph Lameter
2008-02-01  2:38             ` Robin Holt
2008-02-01  2:41               ` Christoph Lameter
2008-02-01  0:01       ` mmu_notifier: close hole in fork Andrea Arcangeli
2008-02-01  1:48         ` Christoph Lameter
2008-02-01  4:24   ` [patch 2/3] mmu_notifier: Callbacks to invalidate address ranges Robin Holt
2008-02-01  4:43     ` Christoph Lameter
2008-02-01 10:32       ` Robin Holt
2008-02-01 10:37         ` Robin Holt
2008-02-01 19:13         ` Christoph Lameter
2008-01-31  4:57 ` [patch 3/3] mmu_notifier: invalidate_page callbacks Christoph Lameter
2008-01-31 17:18 ` [PATCH] mmu notifiers #v5 Andrea Arcangeli
2008-01-31 20:18   ` Christoph Lameter
2008-01-31 23:09     ` Christoph Lameter
2008-01-31 23:41       ` Andrea Arcangeli
2008-02-01  1:44         ` Christoph Lameter
2008-02-01 12:09           ` Andrea Arcangeli
2008-02-01 19:23             ` Christoph Lameter
2008-02-03  2:17               ` Andrea Arcangeli
2008-02-03  3:14                 ` Jack Steiner
2008-02-03  3:33                   ` Andrea Arcangeli
2008-02-04 19:09                 ` Christoph Lameter
2008-02-05  5:25                   ` Andrea Arcangeli
2008-02-05  6:11                     ` Christoph Lameter
2008-02-05 18:08                       ` Andrea Arcangeli
2008-02-05 18:17                         ` Christoph Lameter
2008-02-05 20:55                           ` Andrea Arcangeli
2008-02-05 22:06                             ` Christoph Lameter
2008-02-05 22:12                               ` Robin Holt
2008-02-05 22:26                               ` Andrea Arcangeli
2008-02-05 23:10                                 ` Christoph Lameter
2008-02-05 23:47                                   ` Andrea Arcangeli
2008-02-06  0:04                                     ` Christoph Lameter
2008-01-31 23:28     ` Andrea Arcangeli
2008-02-01  1:37       ` Christoph Lameter
2008-02-01  2:23         ` Robin Holt
2008-02-01  2:26           ` Christoph Lameter
2008-02-01 12:00         ` 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=20080201120028.GW7185@v2.random \
    --to=andrea@qumranet.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=avi@qumranet.com \
    --cc=clameter@sgi.com \
    --cc=daniel.blueman@quadrics.com \
    --cc=holt@sgi.com \
    --cc=izike@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=steiner@sgi.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).