Re: anon_vma RFC2

From: Andrea Arcangeli
Date: Fri Mar 12 2004 - 11:42:49 EST

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.


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

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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at