svn commit: r355227 - head/sys/fs/tmpfs

[Mateusz Guzik]

On 12/1/19, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Sun, Dec 01, 2019 at 12:15:06AM +0100, Mateusz Guzik wrote:
>> On 12/1/19, Konstantin Belousov <kostikbel at 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>