Date: Sun, 1 Dec 2019 00:43:43 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r355227 - head/sys/fs/tmpfs Message-ID: <CAGudoHF=9wcnh_-0H-UbODBBEjD29DJFiq9C1V28imMS857gPg@mail.gmail.com> In-Reply-To: <20191130232452.GC10580@kib.kiev.ua> References: <201911301641.xAUGfmMt029299@repo.freebsd.org> <20191130230725.GB10580@kib.kiev.ua> <CAGudoHF2dxwm_Xytvd2qQxuS6f_KfOtjD%2Bz=%2BEtFwAkoi%2B-vPw@mail.gmail.com> <20191130232452.GC10580@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/1/19, Konstantin Belousov <kostikbel@gmail.com> wrote: > On Sun, Dec 01, 2019 at 12:15:06AM +0100, Mateusz Guzik wrote: >> On 12/1/19, Konstantin Belousov <kostikbel@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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHF=9wcnh_-0H-UbODBBEjD29DJFiq9C1V28imMS857gPg>