I've not reproduced this in testing myself (I don't have SDET);
but the conclusion I've come to is that the length of your vma lists
(for one or probably more files) was such that they were already
dangerously extending the hold of i_shared_sem with Dave's linear-
search-to-sort patch, and my additional downs in move_vma_start
then just pushed it over the edge into a thrash of collisions.
Clearly I was wrong to suppose that move_vma_start would scarcely be
called: even in my testing it showed up ~50% higher than __vma_link,
the other user of __vma_link_file. But we cannot avoid i_shared_sem
there (can probably avoid page_table_lock and I did try doing without
that, just in case my up before spin_unlock had some hideous effect,
but apparently not).
I believe you've done the right thing in 2.5.67-mjb1: chucked out
both my patch and the vma list sorting: it's just too expensive on
the fast path, and you've shown that vividly.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/