Date: Thu, 30 Oct 2025 00:23:47 +0100 From: Lars Tunkrans <drsnx60@gmail.com> To: Stefan Ehmann <shoesoft@gmx.net>, freebsd-stable@freebsd.org Subject: Re: chromium builds very slow with vfs.vnode.param.can_skip_requeue=0 Message-ID: <7cc46e4d-547e-457e-b2bf-0d9514f9be11@gmail.com> In-Reply-To: <055c2d26-98bf-4838-9633-78d1e345fb12@gmx.net> References: <055c2d26-98bf-4838-9633-78d1e345fb12@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7cc46e4d-547e-457e-b2bf-0d9514f9be11>