On Fri, Apr 20, 2012 at 11:54:01AM -0700, Hugh Dickins wrote: > I can see that the discussion has since moved on quite a way from here. > > But it looks to me fairly easy for mm to stop doing fput() under mmap_sem. > > That's already the case when exiting (no mmap_sem held), and shouldn't add > observable cost when unmapping (we already work on a chain of vmas to be > freed, and when unmapping that chain will usually just be of one: shouldn't > matter to defer a final pass until after mmap_sem is dropped). Unless I'm > mistaken, the fput() buried in vma_adjust() can never be a final fput. > > Is it worth my trying to implement that? Or do you see an immediate > gotcha that I'm missing? Or are you happy enough with your deferred > fput() ideas, that it would be a waste of time to rearrange the mm end? Deferring the final pass after dropping ->mmap_sem is going to be interesting; what would protect ->vm_next on those suckers? Locking rules are already bloody complicated in mm/*; this will only add more subtle fun. Note that right now both the dissolution of ->vm_next list and freeing of VMAs happen under ->mmap_sem; changing that might cost us a lot of headache... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
