Re: [andrea@suse.de: Re: 2.6.5-rc2-aa vma merging]

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Mar 30, 2004 at 06:27:18AM +0100, Hugh Dickins wrote:
> On Tue, 30 Mar 2004, Andrea Arcangeli wrote:
> > On Mon, Mar 29, 2004 at 08:44:25PM +0100, Hugh Dickins wrote:
> > 
> > > So I assume that what's there is needed, and the example below
> > > does looks plausible enough: add page, fill it, protect it, ...
> > 
> > this will work perfect, absolutely perfect. You didn't read my code well
> > enough.
> 
> Sure, and I most certainly haven't read your future code well enough.
> Your present implementation, one vma per page (in that real case where
> vmas are properly merged by mainline or anonmm), is far from perfect.
> 
> anon_vma has surprised me more than once by working smoothly just
> where I thought it must go wrong.  Please do surprise me again:
> write that code and post the patch which resolves this doubt.

I will, it just wasn't high prio enough at this time (I mean, I still
have pending some prio-tree bit to fixup with the xfs, that was higher
prio since it impacts functionality, and the mremap race may also be
higher prio).

My point is that merging in your program will work fine, this is what
matters to me, it doesn't right now because I didn't fixup the merging
code yet, but there's nothing that will prevent your program to use just
1 single vma for the whole thing (after I fixup the merging code ;). The
bonus is that after I fixup the merging, it'll use 1 vma even for the
file mappings, not just for anonymous memory, something that is not true
with anonmm (and the complexity of doing file merging or anon-vma
merging is the same, so I will do both at the same cost).