From: Christoph Lameter <clameter@sgi.com>
To: Andrea Arcangeli <andrea@qumranet.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: Tue, 5 Feb 2008 16:04:15 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0802051555380.17243@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20080205234742.GI7441@v2.random>
On Wed, 6 Feb 2008, Andrea Arcangeli wrote:
> > You can of course setup a 2M granularity lock to get the same granularity
> > as the pte lock. That would even work for the cases where you have to page
> > pin now.
>
> If you set a 2M granularity lock, the _start callback would need to
> do:
>
> for_each_2m_lock()
> mutex_lock()
>
> so you'd run zillon of mutex_lock in a row, you're the one with the
> million of operations argument.
There is no requirement to do a linear search. No one in his right mind
would implement a performance critical operation that way.
> > The size of the mmap is relevant if you have to perform callbacks on
> > every mapped page that involved take mmu specific locks. That seems to be
> > the case with this approach.
>
> mmap should never trigger any range_start/_end callback unless it's
> overwriting an older mapping which is definitely not the interesting
> workload for those apps including kvm.
There is still at least the need for teardown on exit. And you need to
consider the boundless creativity of user land programmers. You would not
believe what I have seen....
> > Optimizing do_exit by taking a single lock to zap all external references
> > instead of 1 mio callbacks somehow leads to slowdown?
>
> It can if the application runs for more than a couple of seconds,
> i.e. not a fork flood in which you care about do_exit speed. Keep in
> mind if you had 1mio invalidate_pages callback it means you previously
> called follow_page 1 mio of times too...
That is another problem were we are also in need of solutions. I believe
we have discussed that elsewhere.
--
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:[~2008-02-06 0:04 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 [this message]
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
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=Pine.LNX.4.64.0802051555380.17243@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=a.p.zijlstra@chello.nl \
--cc=andrea@qumranet.com \
--cc=avi@qumranet.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).