chromium builds very slow with vfs.vnode.param.can_skip_requeue=0
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?