Change Details

This will be committed in two parts. Flag field resizing and renumbering prevents the vnode from growing with later addition of v_nchash and will be committed first. This significantly speeds up path lookup, Cascade Lake doing access(2) on ufs on /usr/obj/usr/src/amd64.amd64/sys/GENERIC/vnode_if.c, ops/s: before: 2535298 after: 279762 That is +10%. The reversed order of computation here does not seem to matter. I dumped the namecache populated with > 7 mln and recomputed chain placement with both methods, almost no differences.

This will be committed in two parts. Flag field resizing and renumbering prevents the vnode from growing with later addition of v_nchash and will be committed first. This significantly speeds up path lookup, Cascade Lake doing access(2) on ufs on /usr/obj/usr/src/amd64.amd64/sys/GENERIC/vnode_if.c, ops/s: before: 2535298 after: 279762 That is +10%. The reversed order of computation here does not seem to matter. I dumped the namecache populated with > 7 mln and recomputed chain placement with both methods, almost no differences. I tried to lump this in with v_hash, but unfortunately that one has many testicles elsewhere and in particular is not constant for the lifetime of the vnode.

This will be committed in two parts. Flag field resizing and renumbering prevents the vnode from growing with later addition of v_nchash and will be committed first. This significantly speeds up path lookup, Cascade Lake doing access(2) on ufs on /usr/obj/usr/src/amd64.amd64/sys/GENERIC/vnode_if.c, ops/s: before: 2535298 after: 279762 That is +10%. The reversed order of computation here does not seem to matter. I dumped the namecache populated with > 7 mln and recomputed chain placement with both methods, almost no differences. I tried to lump this in with v_hash, but unfortunately that one has many testicles elsewhere and in particular is not constant for the lifetime of the vnode.