From nobody Wed Oct 29 23:23:47 2025 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cxjx83ykbz6DGQq for ; Wed, 29 Oct 2025 23:23:56 +0000 (UTC) (envelope-from drsnx60@gmail.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cxjx76j3gz3Rkh for ; Wed, 29 Oct 2025 23:23:55 +0000 (UTC) (envelope-from drsnx60@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-362e291924aso3187841fa.1 for ; Wed, 29 Oct 2025 16:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761780229; x=1762385029; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=lS7YX+yhCvaGd2QATLaO7eY7GWI1ZkSnY4oJRZJHPlk=; b=ke6EtlbvCEY7EI5+NuJU9XmW8oEVPptjZKGfmCs1dEPNFY6yPTidDYPe6+pWu9mUID ILeER6kABGN8C/l+hyP1qqsuzjT6NNdIRAtNn1lB8yCFHKWyTL6X91AWK9h/ti5MmWZu ywpNqKJlam8JWvTN+XKpKF7W+jMQoqqB5jq2ccptwDnAt/m+DLL0pGtkVl5UnGryQzq1 r+wwrJgttDnloJ98odChgvhcNUgumAA9gKgV4Gcya02sSdx7navYJdWHtsO06FUn/LFz dBfxVZAX1FhkmMP9QHdwt3VOmevKnLhK3tiaNjBee7cr1x6B84hQtMcTl9GINCFLHgxP z3bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761780229; x=1762385029; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lS7YX+yhCvaGd2QATLaO7eY7GWI1ZkSnY4oJRZJHPlk=; b=hAhHER/oYbc5C7YwJ84JvSIidLm+RUM5HAIvOSmK0UZAD8joOSPj340dTd6vBVbFU4 lO/uZKD89Uv+KZZLY7g8gALEPzgsflg6aus/zYN8ppOjGR2iSqKGMQ+Fz31C8jC/005Z qEAVhbuSj7PE8X9FsI5jTA8myXRJ6YSJAcwfMfvQFfMoAIjaJdt9z1RN9Z0qJhD9Ph9b CBgJNLj6ZcwSJQavBxLeDLbcEvX1y67bkdK7IN1cAvveaTEaXOa1rjLh+zpq6X6ewz/t JTjRJaFGBP6as0sOKsl3j28e4VZkpvwABSMS9MpFJ11RvWI6ZPBcWb36ogLZiXbHppeG tvlg== X-Forwarded-Encrypted: i=1; AJvYcCVdOTbBmYvEMvxORbhmU71Foa/MzVaSg/G6j7eyWaMBg3GvpC6JPjIFl8rmnXh7QFCSQJ2YiwcT4U5LZ1zarg==@freebsd.org X-Gm-Message-State: AOJu0Yx78ABcto6JoBpGzxJ0YFZjMGtsQvxAwMqBF14BJY5YpJrxo73H +1R3lDoB6O2WivSWzz2jO/tyUyqgskjaopnSgh2JGunP4Hrdrr8bRQBs X-Gm-Gg: ASbGncuJKPtT95PLcO+C9FAL3c1V8cwAuiErsJgSEmTPZdEkj/xmVLquVJk1CBgBrGM mwj+bro4fyEjzpW1rOIuXo/wTHmy+1NofTlsRij5GU7qEXIcvPYBE4UjIzUbykEeQPTT8jZIyJ6 ZjBWkTkPrNHHmu0DavWeTo66IyHYKpw4lmC7UGA5gYN3KYQIuVAYTfGkOMpbutxut41x5FY0Dfe GkmuY9QXX6lPPTDOmd0C3Plq0Fxft+US0z2U8axqzARJB/g3QyC7e2rASqLFxwPdcoefo0nTbZZ lRepb7hiNhcCSUdj8caY+dOlwMsk1ZJQ2VqbaDX7o8SFvNuLIGMe1ui4bJ/POVrSu4A7MuSk7Oo uol7BYSnVz7O+TS2xkKHwEKCXuZ7g+W3zoAAhq9J8zH9+76EBEki42HpXIKtiJx+fbJZTTaXzY+ uwg8kmpFk0JTvZBjqBtHWIaNg= X-Google-Smtp-Source: AGHT+IHMbtaxZ9ViDaYsePIUToD28URoq+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? >