Thread (86 messages) 86 messages, 13 authors, 2011-06-18

Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2011-06-17 04:05:38
Also in: lkml

On Thu, Jun 16, 2011 at 2:26 PM, Linus Torvalds
[off-list ref] wrote:
So the unlink_anon_vmas() case is actually much more complicated than
the clone case.

In other words, just forget that second patch. I'll have to think about it.
Ok, I'm still thinking. I have an approach that I think will handle it
fairly cleanly, but that involves walking the same_vma list twice:
once to actually unlink the anon_vma's under the lock, and then a
second pass that does the rest. It should work.

But in the meantime I cleaned up the patch I already sent out a bit,
because the lock/unlock sequence will be the same, so I abstracted it
out a bit and added a couple of comments.

So Tim, I'd like you to test out my first patch (that only does the
anon_vma_clone() case) once again, but now in the cleaned-up version.
Does this patch really make a big improvement for you? If so, this
first step is probably worth doing regardless of the more complicated
second step, but I'd want to really make sure it's ok, and that the
performance improvement you saw is consistent and not a fluke.

                 Linus

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help