From nobody Tue Jun 10 15:53:18 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 4bGtcV3mp8z5xr4q for ; Tue, 10 Jun 2025 15:53:30 +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 4bGtcV237lz3ZYH; Tue, 10 Jun 2025 15:53:30 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1749570810; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/P8P2olRQVkg6uAU4Gwjd4DZIEPs4whcR6r7MiigFJM=; b=Lie3DbSXjZKQxCcUNHQY3BD16iIJR3ADn2ACuGkUq+TuNiiQtSbUxwQgAP5LwcAYJ/NKw1 9jkIS1uTSNq46AbaM/ptGrPg7Y8IDcBt1ggfYHTgGVtJMPnmF3XblTKx5QZxaEXPOLXkec k7HVWdky7RN6xnUMl3naY11M9xvnenTTg+ZP/U1ZhzKjLAcDgpC3SU5V2sBQvtSyKRlNlH rWmnlw9iQVJQMMV3zGCiTmIMTdTG338QT/jaEi6Sx1ANIXatGqBhIjUHr9zAYlxc72slzD 7QmLO9gYWYX83jdGHlrKPcL3kWnuBzgdAvKRsI1GWkGufCqPWT/7fyP52Q4YFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1749570810; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/P8P2olRQVkg6uAU4Gwjd4DZIEPs4whcR6r7MiigFJM=; b=BF40rulmxTyQLLQyOIHYpB3nFbw7JNrKIFO/W9lAdHktQ6fq3nC4g4Fnq+5XY34KBF7AvZ eZ+z/KIGvIR5cX8MIglQT9EaR3d1VRUqO3D/EVWW/mA13DtQLQeieNLAYI59qWJnkmdMQ8 QDLWEKvoN5vFAy2k4qwsFn38NVHUQNCozwqY9C4qaXLrPvwnpmEJl4tr657s3OehtG3UF6 gAS9cG/gJr2jKNlZRkuCDnpf4UUu9Q3paHAkxmO/FuJn0Lt+S7Xj0Xr1EYSrWmenrmsqLM Mwnju6CC3JB6pOHd+9FRnPGcnYihBacqdEvG8dkxfwUJvADAvrRzfmC8L1pr/A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1749570810; a=rsa-sha256; cv=none; b=BVGKNDD51dzdkTCmuyusgRGCLgsTv7AFZf3d6e0EKWheVS2CKqMKK/FYHDPJt4Nm/fCJmG 1gEsi4q+K83yHlfcRH/win9oDWo75Rp8WlJqwv4unbwnrt0hPzB4VRAw0uDHFvx0Lv7e4b esNsvh1ygp0e+1zXgDgBYEHoDe1FhtsEFvWZz4gUsd7lGZMmoALrAbArr3d4H10f+goc9c yfpNRauierjVSgbyfk5TIiM4eC/g0qowYkpO8lmssIwIzzlTcXpQntgSZWyj9swWKRo1Yk XewI7pjqodvji8Uo6wQe8eRx2JjFgEXlIla9DZe8gC3H/xi7YfN1Kxhk03PO7Q== 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 4bGtcV1JjJzHSn; Tue, 10 Jun 2025 15:53:30 +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 84882110E4; Tue, 10 Jun 2025 16:53:29 +0100 (BST) Content-Type: text/plain; charset=utf-8 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 From: David Chisnall In-Reply-To: Date: Tue, 10 Jun 2025 16:53:18 +0100 Cc: Warner Losh , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <0EE4942C-1C27-48F6-B778-0596C3A99593@FreeBSD.org> References: To: Minsoo Choo X-Mailer: Apple Mail (2.3776.700.51.11.1) On 10 Jun 2025, at 16:22, Minsoo Choo wrote: >=20 > snmalloc by Microsoft - David's suggestion. Yet mimalloc also provides = some security features ("guard pages, randomized allocation, encrypted = free lists, etc. to protect against various heap vulnerabilities") as = well. Still in 0.x stage. >=20 > snmalloc and mimalloc look great for me, but my only concern is that = snmalloc is still in 0.x stage. It=E2=80=99s being used in production in multiple quite different use = cases. The main reason it isn=E2=80=99t 1.0 is that we may change some = of the internal APIs. This doesn=E2=80=99t matter for use as a global = allocator, because those APIs are stable (defined by C, C++, or Rust, = not things that we can change). snmalloc also has a number of security features (the bounds checking = alone addresses 10% of critical CVEs in the data set that we looked at = and probably has a bigger security impact than anything else). The = hardening things are discussed here: https://github.com/microsoft/snmalloc/tree/main/docs/security It=E2=80=99s also the allocator that we=E2=80=99ve used with a lot of = the CHERI work, so when the CheriBSD things are upstreamed it=E2=80=99s = easy to adopt. Supporting CHERI with mimalloc would be quite tricky. On 10 Jun 2025, at 13:47, Poul-Henning Kamp wrote: >=20 > David Chisnall writes: >=20 >> I've replaced jemalloc with snmalloc (to which I am a contributor) >=20 > It looks interesting, but rather than all of us having to do our > own homework, can you give us the "elevator pitch" for it ? Beyond the things I wrote in my previous mail: Snmalloc is a sizeclass allocator designed for concurrent workloads. = All allocations are preformed by a thread-local allocator, so there is = no locking required on the fast path for allocation. Frees from the = same thread are handled locally. Frees from remote threads are batched = (by default, up to 1 MiB of freed objects) and then sent back to the = original allocator using a lightweight message queue (single atomic = exchange to send a set of allocations, forward-progress guarantees). = This means that allocating on one thread and freeing on another (which = is the pathological case for thread-caching allocators, but a common = thing on multithreaded codebases) is really fast. The platform abstractions are cleanly separated (we try very hard to = avoid #ifdef) in most of the code. Here is the FreeBSD platform layer: = https://github.com/microsoft/snmalloc/blob/main/src/snmalloc/pal/pal_freeb= sd.h Architecture abstractions are *mostly* orthogonal to platforms, and = snmalloc supports all of the architectures that FreeBSD supports, = here=E2=80=99s the full set (note: CHERI is a mixin rather than a = separate architecture): https://github.com/microsoft/snmalloc/tree/main/src/snmalloc/aal For producer-consumer workloads, we=E2=80=99ve seen speedups of 50% = relative to thread-caching allocators like jemalloc. For = single-threaded workloads or workloads where allocation and deallocation = happen on the same thread, we=E2=80=99ve seen smaller speedups. David