From nobody Tue Jun 10 07:15:02 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 4bGg6R5SKXz60FmD for ; Tue, 10 Jun 2025 07:15:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bGg6R3mbPz3Lmg; Tue, 10 Jun 2025 07:15:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1749539711; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Bok184Mm7qstoG2FhvusVFhaTB4Aj3AU1IXwPexrvOs=; b=e5IgMbvH/KkEvkwSZcL65MRTdJcu1lPec4uLYTuSAb8/4FDSGJJhdY30gtF1bzpGjeuTVk CK4pYJuJFfxvMcIDMU6b1kr5wT5k3hxsQwzxhGR6YqGi8hPxZSM3qHf2cnjSWYkRJdHzBQ Z6AB8SHY7SM2bHb+0oIrTjIb6BvlBHOgqnBc1rkpZWI+jKOXfkKEz032qH0RaUylvSpNrF Q1ccKHgDFBo2L4G9xNhETMmPguMQTx7++bj7wOuwgIGzfyGtDiCtcyqD6CUvFrymRhIT2V mm/5LDQA8oN3gen0kzDJty4+aeaVImkkZVZ82xXJuMDFUmfceur3sda1Cvb5Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1749539711; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Bok184Mm7qstoG2FhvusVFhaTB4Aj3AU1IXwPexrvOs=; b=kYP+5VHEO4TvgCq2SY0inSkeCytYzVtCsPf3ANBef/K6fhR1NVtL0YQ3IdA8lLo1U/QB3G 67QHKSe98e8iRXgr0X/h0RfRwyDkXd02s6Wi4wPJPthgAZwIxaDvQhVH52VHu80JoNFsLT Jap6a3KrwcXN2VFDzhCnuFrQCCIMAUw7lZQz53ZWBvYdWXMcwDpizYinREiD10gei28PX/ 33kbq2CcgRVK/60JHAN4rzO3VVIiOG7dFCx4XgfIrmQStzkw5+bKhZMCtplHy4OBD/Xknp dL812/R0aRwo+h5kNr2k65Z35hdA3waebLJNGvIjfCEZFo9DuQiXUmNiez4vQg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1749539711; a=rsa-sha256; cv=none; b=Mrqq9JOl0Z8gSiduz+rUS/Bmf+BrFdRLvYveCcGlq4Gfi7XT8SjtmDo7Kdi43hcx78QZiZ KOC5CBKbT2Uo14ruPuG/7HAyp6qvqyeY9KAh5+sKv+e8F9s6Z2l9oYJnWc54cHmEVBr2kU H0ne30VJfniBEN379LkSZIrgiBakKMCRIaKwO+4dpC3k2WXXkL1KW8QB1+0wGfSwBvD4zT lFmxD3E19JfCnr+DE9JsDizQ+eT3nE4AyWycVjrqnVgwkg8nF4ke1uFdG3rrSAY8zycnNv jbhr5YfzrRj/DTAQkVyz5cSFKmRujVw1GoDckFsLcxeCbdsTH6y2F5QspB+ZHA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4bGg6R1nrwz6Tn; Tue, 10 Jun 2025 07:15:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host86-143-41-189.range86-143.btcentralplus.com [86.143.41.189]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 9D0A5110DB; Tue, 10 Jun 2025 08:15:10 +0100 (BST) From: David Chisnall Message-Id: <44DDF236-0911-4CE8-AD30-5E1AB5CB25EB@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_C41C6228-FC4D-43CC-AB37-68FC85CE7B7A" 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 (Mac OS X Mail 16.0 \(3776.700.51.11.1\)) Subject: Re: Future of jemalloc on FreeBSD after archive Date: Tue, 10 Jun 2025 08:15:02 +0100 In-Reply-To: Cc: Minsoo Choo , FreeBSD CURRENT To: Warner Losh References: X-Mailer: Apple Mail (2.3776.700.51.11.1) --Apple-Mail=_C41C6228-FC4D-43CC-AB37-68FC85CE7B7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 10 Jun 2025, at 00:17, Warner Losh wrote: >=20 > I'm unsure what to do in the future. What are all the cool kids using = today? I=E2=80=99ve replaced jemalloc with snmalloc (to which I am a = contributor) in libc about five years ago and have been using that on a = few places. I believe Brooks imported a cleaned-up version of my = patches to CheriBSD and was planning on upstreaming them as an option. - For building llvm, snmalloc was around 2% faster. I didn=E2=80=99t = do much benchmarking because I was mostly on VMs but across SPEC on = Linux (where we did more benchmarking) we were typically faster than = jemalloc. - The libc binary is around 500 KiB smaller. - The HAL supports FreeBSD upstream (there=E2=80=99s also a HAL for = running snmalloc in the kernel too, but it is bitrotted). It=E2=80=99s = easy to tune things for performance or memory overhead. - It makes it easy to do fun things like allocate across trust = boundaries. We use this in the verona-sandbox project to easily = compartmentalise libraries with capsicum. We built snmalloc as a set of = tools to build allocators, rather than as a malloc. The same code can = be used to build specialised allocators. - It makes it easy to find the start and end of allocations. My = version has checks on memcpy and an older prototype did bounds checks on = things like sprintf and so on. These have around a 2% performance = overhead with checks on writes. I have some ifunc magic to dynamically = switch between the two versions for memcpy. Not that I=E2=80=99m biased or anything... David --Apple-Mail=_C41C6228-FC4D-43CC-AB37-68FC85CE7B7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 10 Jun = 2025, at 00:17, Warner Losh <imp@bsdimp.com> = wrote:

I'm unsure what to do in the future. What = are all the cool kids using today?

I=E2=80=99ve replaced jemalloc = with snmalloc (to which I am a contributor) in libc about five years ago = and have been using that on a few places.  I believe Brooks = imported a cleaned-up version of my patches to CheriBSD and was planning = on upstreaming them as an option.

 - For = building llvm, snmalloc was around 2% faster.  I didn=E2=80=99t do = much benchmarking because I was mostly on VMs but across SPEC on Linux = (where we did more benchmarking) we were typically faster than = jemalloc.
 - The libc binary is around 500 KiB = smaller.
 - The HAL supports FreeBSD upstream (there=E2=80=99= s also a HAL for running snmalloc in the kernel too, but it is = bitrotted).  It=E2=80=99s easy to tune things for performance or = memory overhead.
 - It makes it easy to do fun things = like allocate across trust boundaries.  We use this in the = verona-sandbox project to easily compartmentalise libraries with = capsicum.  We built snmalloc as a set of tools to build allocators, = rather than as a malloc.  The same code can be used to build = specialised allocators.
 - It makes it easy to find the = start and end of allocations.  My version has checks on memcpy and = an older prototype did bounds checks on things like sprintf and so on. =  These have around a 2% performance overhead with checks on writes. =  I have some ifunc magic to dynamically switch between the two = versions for memcpy.

Not that I=E2=80=99m = biased or = anything...

David

= --Apple-Mail=_C41C6228-FC4D-43CC-AB37-68FC85CE7B7A--