chromium builds very slow with vfs.vnode.param.can_skip_requeue=0

From: Stefan Ehmann <shoesoft_at_gmx.net>
Date: Wed, 29 Oct 2025 22:50:04 UTC
After updating from 14.3 to 15.0-BETA I've noticed that chromium builds 
in poudriere slow down to a crawl after some time. top shows > 95% 
system usage.

dtrace/hotkernel shows > 90% spent in kernel`lock_delay.

dtrace -n 'fbt::lock_delay:entry { @[stack()] = count(); }' has lots of 
traces similar to this one:

kernel`__mtx_lock_sleep+0xe8
kernel`vdbatch_process+0x4fb
kernel`vdropl+0x20e
kernel`vput_final+0xa3
kernel`vn_close1+0x186
kernel`vn_closefile+0x3d
kernel`_fdrop+0x11
kernel`closef+0x24a
kernel`closefp_impl+0x58
kernel`amd64_syscall+0x126
kernel`0xffffffff809f8a0b

In vdbatch_process() there is the following comment above the condition 
that is controlled by vfs.vnode.param.can_skip_requeue:

/*
  * Attempt to requeue the passed batch, but give up easily.
  *
  * Despite batching the mechanism is prone to transient *significant*
  * lock contention, where vnode_list_mtx becomes the primary bottleneck
  * if multiple CPUs get here (one real-world example is highly parallel
  * do-nothing make , which will stat *tons* of vnodes). Since it is
  * quasi-LRU (read: not that great even if fully honoured) provide an
  * option to just dodge the problem. Parties which don't like it are
  * welcome to implement something better.
  */
if (vnode_can_skip_requeue) {
...

Setting "sysctl vfs.vnode.param.can_skip_requeue=1" remedies the 
situation immediately and system usage returns to ~15%.

I cannot recall such problems in 14.3, is this a regression in 15.x?