oq+MCc/+OXmlYc0NDg3TXM6dcPm1+8a5z5/ryace2i2NgXw== X-Received: by 2002:a05:651c:2347:10b0:376:3b32:ad9c with SMTP id 38308e7fff4ca-37a023fcdc3mr12143631fa.23.1761780228734; Wed, 29 Oct 2025 16:23:48 -0700 (PDT) Received: from [192.168.1.100] (2.71.208.189.mobile.tre.se. [2.71.208.189]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-378ee0e5239sm37559171fa.53.2025.10.29.16.23.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Oct 2025 16:23:48 -0700 (PDT) Message-ID: <7cc46e4d-547e-457e-b2bf-0d9514f9be11@gmail.com> Date: Thu, 30 Oct 2025 00:23:47 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: chromium builds very slow with vfs.vnode.param.can_skip_requeue=0 To: Stefan Ehmann , freebsd-stable@freebsd.org References: <055c2d26-98bf-4838-9633-78d1e345fb12@gmx.net> Content-Language: en-US From: Lars Tunkrans In-Reply-To: <055c2d26-98bf-4838-9633-78d1e345fb12@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cxjx76j3gz3Rkh   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? >