From nobody Mon Dec 8 00:15:33 2025 X-Original-To: freebsd-current@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 4dPjF12ctQz6J4vC; Mon, 08 Dec 2025 00:15:49 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dPjF10cdVz472y; Mon, 08 Dec 2025 00:15:48 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5B80FYBa081163; Mon, 8 Dec 2025 02:15:37 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5B80FYBa081163 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5B80FXPh081162; Mon, 8 Dec 2025 02:15:33 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Mon, 8 Dec 2025 02:15:33 +0200 From: Konstantin Belousov To: Mateusz Guzik Cc: Warner Losh , Mark Millard , FreeBSD Current , FreeBSD-STABLE Mailing List Subject: Re: performance regressions in 15.0 Message-ID: References: <18FB2858-5CBB-4B7A-8089-224A58C6A160@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dPjF10cdVz472y On Sun, Dec 07, 2025 at 11:30:41AM +0100, Mateusz Guzik wrote: > On Sat, Dec 6, 2025 at 11:26 PM Warner Losh wrote: > > A few months before I landed the jemalloc patches, i did 4 or 5 from dirt buildworlds. The elasped time was, iirc, with 1 or 2%. Enough to see maybe a diff with the small sample size, but not enough for ministat to trigger at 95%. I didn't recall keeping the data for this and can't find it now. And I'm not even sure, in hindsight, I ran a good experiment. It might be related, or not, but it would be easy enough for someone to setup a two jails: one just before and one just after. Build from scratch the world (same hash) on both. That would test it since you'd be holding all other variables constant. > > > > When we imported the tip of FreeBSD main at work, we didn't get a cpu change trigger from our tests that I recall... > > > > Note you probably build tested with clang which was already penalized. > > I just verified that going to libc as of this commit: > commit c43cad87172039ccf38172129c79755ea79e6102 (HEAD) > Merge: da260ab23f26 48ec896efb0b > Author: Warner Losh > Date: Mon Aug 11 17:38:36 2025 -0600 > > jemalloc: Merge from jemalloc 5.3.0 vendor branch > > retains the perf problem as seen in the malloc microbenchmarks > > and that going to one commit prior bring it back in line with 14.3 > > built like so from lib/libc: > make -s -j 8 WITHOUT_TESTS=1 MALLOC_PRODUCTION=yes all install > > Given that jemalloc prior to the import is a well known working state, > I think it will be most prudent to revert the update for the time > being and investigate it later. > > Note both jemalloc itself and clang aside, there is the issue of > slower binary startup in the first place (see the doexec.c parts in my > e-mail). > > Given the magnitude of the slowdowns, the above two are definitely EN > material. Sorting out the startup thing should qualify depending on > complexity of the fix, whatever it might be. > I completely disagree. NO_SHARED toolchain was the remnant from the pre-historic times where migration to the ELF was performed, I believe. It was a precaution to make it possible to recover the system in case the rtld/dynamic libc installation gone wrong. In other words, non-shared toolchain is a mistake on its own. Next, the change of llvm components to dynamically link with the llvm libs is how upstream does it. Not to mention, that this way to use clang+lld saves both disk space (not very important) and memory (much more important). The implied load on rtld is something that could be handled: there is definitely no need to have such huge surface of exported symbols on both libllvm and esp. libclang. Perhaps by default the internal libraries can use protected symbols, normally C++ do not rely on interposing. But such 'fixes' must occur at upstream. So far all the clang toolchain changes were aligning it with what the llvm project does.