Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > Have you tried to profile something like umount -l on a large mount tree? > You variant causes a shitstorm of > schedule work > switch to workqueue > do actual fs shutdown > wake umount(8) up > get through wait_for_completion() > for every bleeding vfsmount in there. And no, it's *not* guaranteed to > be dominated by fs shutdown time. Here's the case where it definitely > won't be: > mkdir /tmp/a > mount --rbind / /tmp/a > umount -l /tmp/a > > All vfsmounts involved are killed off with no fs shutdown. And that's > *not* a rare case - exit of the last process in namespace is very likely > to look that way too. > > That's far too heavy. The typically system has about 12 mounts and no mount namespaces. Making umount of any kind a rare case. Al my apologies for not picking your favorite solution and in choosing not to audit every call to mntput in the tree this week I have made an uncommon case slower. These bug fixes are important, the code is correct, and it is technically straight forward to remove the wait in mntput in most cases. I am very frustrated that when given lots of opportunities to look at and comment on my code it is hard to get you to engage and comment unless I send a pull request to Linus. This last objection really looks to be a case of perfection getting in the way of the good. Eric -- 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
