Re: [PATCH] mm: munlock use mapcount to avoid terrible overhead

[Andi Kleen]

Hugh Dickins <hughd@xxxxxxxxxx> writes:

> A process spent 30 minutes exiting, just munlocking the pages of a large
> anonymous area that had been alternately mprotected into page-sized vmas:
> for every single page there's an anon_vma walk through all the other
> little vmas to find the right one.

We had the same problem recently after a mmap+touch workload: in this
case it was hugepaged walking all these anon_vmas and the list was over
100k long. 

Had some data on this at plumbers:
http://halobates.de/plumbers-fork-locks_v2.pdf

> A general fix to that would be a lot more complicated (use prio_tree on
> anon_vma?), but there's one very simple thing we can do to speed up the
> common case: if a page to be munlocked is mapped only once, then it is
> our vma that it is mapped into, and there's no need whatever to walk
> through all the others.

I think we need a generic fix, this problem does not only happen
in munmap. 


-Andi
-- 
ak@xxxxxxxxxxxxxxx -- Speaking for myself only
--
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/