From: Andrea Arcangeli <andrea@suse.de>
To: Rajesh Venkatasubramanian <vrajesh@umich.edu>
Cc: riel@redhat.com, linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: anon_vma RFC2
Date: Sun, 14 Mar 2004 01:23:48 +0100 [thread overview]
Message-ID: <20040314002348.GQ30940@dualathlon.random> (raw)
In-Reply-To: <Pine.GSO.4.58.0403131426590.12823@blue.engin.umich.edu>
On Sat, Mar 13, 2004 at 02:40:09PM -0500, Rajesh Venkatasubramanian wrote:
> Agreed. prio_tree is only useful for anon_vma. But, after
> linus-unshare-mremap, the anon_vma patch can be modified
> (simplified ?) a lot. You don't need any as.anon_vma, as.vma
> pointers in the page struct. You just need the already existing
> page->mapping and page->index, and a prio_tree of all anon vmas.
what you are missing is that we don't need a prio_tree at all with
anonmm+linus-unshare-mremap, prio tree can make sense only with
anon_vma, not with anonmm. the vm_pgoff is meaningless with anonmm.
find_vma (and the rbtree) already does the trick with anonmm. the
linus-unshare-mremap guarantees that a certain physical page will be
only at a certain virtual address in every mm, so prio_tree taking pgoff
into account isn't needed there, find_vma is more than enough.
any prio_tree can't fix anyways the problem that anonmm will force
the vm to scan all mm at the page->index address, even for a newly
allocated malloc region. that is optimized away by anon_vma, plus
anon_vma avoids the early-COW in mremap. the relevant downside of
anon_vma is that it takes some more byte in the vma to provide those
features.
next prev parent reply other threads:[~2004-03-14 0:23 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040310080000.GA30940@dualathlon.random>
2004-03-10 13:01 ` [lockup] Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines) Rik van Riel
2004-03-10 13:50 ` Andrea Arcangeli
2004-03-12 17:05 ` anon_vma RFC2 Rajesh Venkatasubramanian
2004-03-12 17:26 ` Andrea Arcangeli
2004-03-12 21:16 ` Rajesh Venkatasubramanian
2004-03-13 17:55 ` Rajesh Venkatasubramanian
2004-03-13 18:16 ` Andrea Arcangeli
2004-03-13 19:40 ` Rajesh Venkatasubramanian
2004-03-14 0:23 ` Andrea Arcangeli [this message]
2004-03-14 0:52 ` Linus Torvalds
2004-03-14 1:01 ` William Lee Irwin III
2004-03-14 1:07 ` Rik van Riel
2004-03-14 1:19 ` William Lee Irwin III
2004-03-14 1:41 ` Rik van Riel
2004-03-14 2:27 ` William Lee Irwin III
2004-03-14 1:15 ` Linus Torvalds
2004-03-11 20:09 Manfred Spraul
-- strict thread matches above, loose matches on Subject: below --
2004-03-08 20:24 objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines) Andrea Arcangeli
2004-03-09 10:52 ` [lockup] " Ingo Molnar
2004-03-09 11:02 ` Ingo Molnar
2004-03-09 11:09 ` Andrew Morton
2004-03-09 11:49 ` Ingo Molnar
2004-03-09 16:03 ` Andrea Arcangeli
2004-03-10 10:36 ` RFC anon_vma previous (i.e. full objrmap) Andrea Arcangeli
2004-03-11 6:52 ` anon_vma RFC2 Andrea Arcangeli
2004-03-11 13:23 ` Hugh Dickins
2004-03-11 13:56 ` Andrea Arcangeli
2004-03-11 21:54 ` Hugh Dickins
2004-03-12 1:47 ` Andrea Arcangeli
2004-03-12 2:20 ` Andrea Arcangeli
2004-03-12 3:28 ` Rik van Riel
2004-03-12 12:21 ` Andrea Arcangeli
2004-03-12 12:40 ` Rik van Riel
2004-03-12 13:11 ` Andrea Arcangeli
2004-03-12 16:25 ` Rik van Riel
2004-03-12 17:13 ` Andrea Arcangeli
2004-03-12 17:23 ` Rik van Riel
2004-03-12 17:44 ` Andrea Arcangeli
2004-03-12 18:18 ` Rik van Riel
2004-03-12 18:25 ` Linus Torvalds
2004-03-12 18:48 ` Rik van Riel
2004-03-12 19:02 ` Chris Friesen
2004-03-12 19:06 ` Rik van Riel
2004-03-12 19:10 ` Chris Friesen
2004-03-12 19:14 ` Rik van Riel
2004-03-12 20:27 ` Andrea Arcangeli
2004-03-12 20:32 ` Rik van Riel
2004-03-12 20:49 ` Andrea Arcangeli
2004-03-12 21:08 ` Jamie Lokier
2004-03-12 12:42 ` Andrea Arcangeli
2004-03-12 12:46 ` William Lee Irwin III
2004-03-12 13:24 ` Andrea Arcangeli
2004-03-12 13:40 ` William Lee Irwin III
2004-03-12 13:55 ` Hugh Dickins
2004-03-12 16:01 ` Andrea Arcangeli
2004-03-12 16:17 ` Linus Torvalds
2004-03-13 0:28 ` William Lee Irwin III
2004-03-13 14:43 ` Rik van Riel
2004-03-13 16:18 ` Linus Torvalds
2004-03-13 17:24 ` Hugh Dickins
2004-03-13 17:28 ` Rik van Riel
2004-03-13 17:41 ` Hugh Dickins
2004-03-13 18:08 ` Andrea Arcangeli
2004-03-13 17:54 ` Andrea Arcangeli
2004-03-13 17:55 ` Andrea Arcangeli
2004-03-13 18:57 ` Linus Torvalds
2004-03-13 19:14 ` Hugh Dickins
2004-03-13 17:48 ` Andrea Arcangeli
2004-03-13 17:33 ` Andrea Arcangeli
2004-03-13 17:53 ` Hugh Dickins
2004-03-13 18:13 ` Andrea Arcangeli
2004-03-13 19:35 ` Hugh Dickins
2004-03-13 17:57 ` Rik van Riel
2004-03-12 13:43 ` Hugh Dickins
2004-03-12 15:56 ` Andrea Arcangeli
2004-03-12 16:12 ` Hugh Dickins
2004-03-12 16:39 ` Andrea Arcangeli
2004-03-11 17:33 ` Andrea Arcangeli
2004-03-11 22:20 ` Rik van Riel
2004-03-11 23:43 ` Hugh Dickins
2004-03-12 3:20 ` Rik van Riel
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=20040314002348.GQ30940@dualathlon.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
--cc=torvalds@osdl.org \
--cc=vrajesh@umich.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.