tmpfs vs VV_LOCKSWORK

[Mateusz Guzik <mjguzik%gmail.com@localhost>]

tmpfs does *NOT* set the flag. While I can't be arsed to verify
semantics, I suspect it is more than eligible.

This came up as a slowdown in an "access" microbenchmark with target
file on tmpfs, stemming from:

commit 5645873e2da675f475c8b8d61260c8ffe9d411ab
Author: riastradh <riastradh%NetBSD.org@localhost>
Date:   Tue Aug 4 03:00:10 2020 +0000

    Fix bogus fast path in vput.

I wrote a trivial patch for it (see below).
Results are (ops/s):
stock: 1721941
aug 4: 1592518
patch: 1664363

The difference stems from calling VOP_ISLOCKED.

The patch is a PoC, I don't claim much correctness. Basically
someone(tm) will have to take care of the problem.
diff --git a/sys/fs/tmpfs/tmpfs_subr.c b/sys/fs/tmpfs/tmpfs_subr.c
index 92a0eedf4443..394320fe71ce 100644
--- a/sys/fs/tmpfs/tmpfs_subr.c
+++ b/sys/fs/tmpfs/tmpfs_subr.c
@@ -136,6 +136,8 @@ tmpfs_init_vnode(struct vnode *vp, tmpfs_node_t *node)
                /* FALLTHROUGH */
        case VLNK:
        case VREG:
+               vp->v_vflag |= VV_LOCKSWORK;
+               /* FALLTHROUGH */
        case VSOCK:
                vp->v_op = tmpfs_vnodeop_p;
                break;

-- 
Mateusz Guzik <mjguzik gmail.com>