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 <[email protected]> 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>
