What is the size of RAM in your machine. ?
When building Chrome / ungoogled-chrome on 15-current at
some time this spring, About 18 GB
RAM was used on a 64 GB machine. And then you need RAM for
the ZFS ARC cache., if you have the source code on ZFS, Therefor you
need 32 GB RAM to build Chrome efficiently.
I think I remember that using Link Time Optimization option also
took a long time at the end of the build.
Regards.
On 10/29/25 11:50 PM, Stefan Ehmann wrote:
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?
