On 12/1/19, Konstantin Belousov <kostik...@gmail.com> wrote: > On Sun, Dec 01, 2019 at 12:15:06AM +0100, Mateusz Guzik wrote: >> On 12/1/19, Konstantin Belousov <kostik...@gmail.com> wrote: >> > On Sat, Nov 30, 2019 at 04:41:48PM +0000, Mateusz Guzik wrote: >> >> Author: mjg >> >> Date: Sat Nov 30 16:41:47 2019 >> >> New Revision: 355227 >> >> URL: https://svnweb.freebsd.org/changeset/base/355227 >> >> >> >> Log: >> >> tmpfs: add fast path to tmpfs_access for common case lookup >> >> >> >> VEXEC consists of vast majority of all calls and almost all targets >> >> have >> >> at least 0111. >> > On what load VEXEC is the dominant access check ? >> > >> >> Note this is called for every directory to be traversed dooring lookup, >> so for instance looking up "foo/bar/baz" performs 2 VEXEC checks. > So it is for directory components traversal during lookup. > Does it make sense to add something similar at the start of > ufs_accessx() when neither kind of ACLs is enabled for mp ? >
All filesystems should short-circuit it if they can. I have a review of the sort for zfs which internally was using a step forward in this idea by checking if any exec perms are denied: https://reviews.freebsd.org/D22224 However, if talking about ufs performance, I think the bigger fish to fry is ufs_need_inactive. While I have not benchmarked, if tmpfs and zfs are of any help, concurrent path lookup will keep contending on vputx relocking the vnode in exclusive manner. This not only slows things down as it is, It is a hard blocker for using adaptive spinning in lockmgr for this fs. I may get around to providing both much later, but I suspect you are much more familiar with the fs than I am and could do it significantly faster. -- Mateusz Guzik <mjguzik gmail.com> _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
