Re: anon_vma RFC2

Andrea Arcangeli
2004-03-12T16:38:55Z

On Fri, Mar 12, 2004 at 04:12:10PM +0000, Hugh Dickins wrote:
> > you're right about vma_split, the way I implemented it is wrong,
> > basically the as.vma/PageDirect idea is falling apart with vma_split.
> > I should simply allocate the anon_vma without passing through the direct
>
> Yes, that'll take a lot of the branching out, all much simpler.

indeed.

> Simpler still to allocate it earlier? Perhaps too wasteful.

one trouble with allocate it earlier is that insert_vm_struct would need
to return a -ENOMEM retval, plus things like MAP_PRIVATE don't
necessairly need an anon_vma ever (true anon mappings tends to need it
always instead ;).

So I will have to add a anon_vma_prepare(vma) near all SetPageAnon.
that's easy. Infact I may want to coalesce the two things together, it
will look like:

int anon_vma_prepare_page(vma, page) {
if (!vma->anon_vma) {
vma->anon_vma = anon_vma_alloc()
if (!vma->anon_vma)
return -ENOMEM;
/* single threaded no locks here */
list_add(&vma->anon_vma_node, &anon_vma->anon_vma_head);
}
SetPageAnon(page);

return 0;
}

I will have to handle a retval failure from there, that's the only
annoyance of removing the PageDirect optimization, I really did the
PageDirect mostly to leave all the anon_vma allocations to fork().

Now it's the exact opposite, fork will never need to allocate any
anon_vma anymore, it will only boost the page->mapcount.