Re: anon-vma (and now filebacked-mappings too) mprotect vma merging [Re: 2.6.5-rc2-aa vma merging]

[Hugh Dickins]

On Sat, 3 Apr 2004, Andrea Arcangeli wrote:
> 
> another relevant advantage of anon-vma compared to anonmm, is the smp
> locking scalability and simplicity. With anonmm you're either forced to
> keep the mm-wide page_table_lock during vma merging and in general
> during all vma modifications (so you can lookup the rbtree from
> try_to_unmap by trylocking on the page_table_lock). While with anon-vma
> the page_table_lock goes away completely from the vma merging and all
> vma manipulations. page_table_lock remains but only for accessing the
> pagetables.

I liked Andrew's vma->page_table_lock suggestion, was imagining we
should migrate in that direction (as you said at the time, needn't
be right now), if only as a discipline to force us away from the
page_table_lock or mmap_sem muddle in (not your version of) mmap.c.

So I had been expecting to shift anonmm in that direction,
needing to do a down_read_trylock around its anon find_vma.

By the way, your and my page_referenced_one do need to take
page_table_lock, but the need for it is very very slender: Dave
took it out a year ago, I persuaded him it had to go back in,
but there's probably some way we can avoid it later on.

> About the ppc page->mapping stuff I don't think the ppc fixes in
> anobjrmap are really going to fix anything, though that tlb.c code is
> very confusing to me, not sure how can it work without it, but OTOH then
> even mainline shouldn't work if that's needed. ppc help?

I just translated what was there before: I thought I could understand
why it did that on user page tables, but I couldn't understand why it
did it to all the kernel page tables too.

I believe it's related to the fact that page_referenced_one does not
flush TLB after ptep_test_and_clear_referenced: so MMU may not notice
that we have cleared it, and not set it again even though referenced;
so pages referenced very frequently may be treated as unreferenced.
We ought to flush TLB there, but I presume it's been thought
to waste more time than its worth (particularly across cpus).
Probably depends rather on architecture, hence the ppc code.

Hugh

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/