On Sat, Dec 6, 2025 at 11:26 PM Warner Losh <[email protected]> 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 <[email protected]> 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.
