From nobody Thu Feb 09 19:46:16 2023 X-Original-To: freebsd-hackers@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 4PCS6Z73QBz3nVwM for ; Thu, 9 Feb 2023 19:46:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PCS6Z5NYVz3q68 for ; Thu, 9 Feb 2023 19:46:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62d.google.com with SMTP id ud5so9740244ejc.4 for ; Thu, 09 Feb 2023 11:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QN0nwEGlmDwHpF6jDQanZpOi8UQsgzItg62WPcp+nH4=; b=hxzaFLEmxeM+tzQAi0yh5nOoafmlW2l0p/TgfW6eFIsMR0miF/70du8Snb8SIGwuS1 UXPV3Hi9Q7OWbZRUAFLPjKraMhn3ZoRQn/GIWuAdklhu4BiLCI6KEYtZ+a+exHJ1Bcmi JUBoEcI8V+rRFb2TbmHBIoqyBpPL5wJiq2YzLGGgKiYY8D+4NuP76YIrImE3iKtb8ZZQ 1ICLQV46RWSFvHOsLJ9Y5qJOL/J3SZMgbFB03oyHs/EYwLp+LngbdJXMFEjbNDrsbvlJ 12Ca9vS5xK2tgehVEUcXcI2pE6fp0BQoyNrOb/o+WJpJ30IUFqh6OuwrzAtWG0xul0vg 20Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QN0nwEGlmDwHpF6jDQanZpOi8UQsgzItg62WPcp+nH4=; b=5+O7CgPJI0aQAnIb8WhU5LA1KSISodIcVVzCN93+j/uP2FFLGQm9OXlLoh7+KYxNBC pMo5k4pljp54jbWrv0zbxfe3UZLUZHn6XJubt6FmJdcc2+lluqG6g3zhTSJ859ahES0p v6SX9ErLlNlYrWXUAJWr/Rktrb4+T3DAiP+TnIcWwXw1X9SQlusO/G3xM1G88IXEZx61 sT61Yw+a4aYHbSkqC1VQoI+DSLKSGP8gItevOVIcaYVwVhnG9Ro18B5wDQ56nQGO2uIl Jno9c5ur+aBuLBda3wkRKReGu+ZaiScVZvqTSQrmsAoBxckVguCHnjK+hCJJcfmqWcPk 62Cg== X-Gm-Message-State: AO0yUKWAsCcr3Wy5ey6E8S6TFHcAFfwK2hZo/RlFPcekKfu2/aP0Z3Cl s4WOwm7zFcX/UJNHHv6FElTd3Hn5EBd0T74/g8uPyrqyTH+HJw== X-Google-Smtp-Source: AK7set9oo8XzGvxFONpBWhxJokMMVhqRSAI22MxvxKYPipltfxCwJ6xYkydhooL1BUv7HMuXtOrfroYHSgFZfu0qZzo= X-Received: by 2002:a17:906:2f17:b0:888:c14e:70b6 with SMTP id v23-20020a1709062f1700b00888c14e70b6mr2877113eji.306.1675971989063; Thu, 09 Feb 2023 11:46:29 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <2f3dcda0-5135-290a-2dff-683b2e9fe271@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Thu, 9 Feb 2023 12:46:16 -0700 Message-ID: Subject: Re: CFT: snmalloc as libc malloc To: David Chisnall Cc: Mateusz Guzik , freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000000fdb0105f449a32b" X-Rspamd-Queue-Id: 4PCS6Z5NYVz3q68 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-ThisMailContainsUnwantedMimeParts: N --0000000000000fdb0105f449a32b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 9, 2023, 12:37 PM David Chisnall wrote: > On 9 Feb 2023, at 19:15, Mateusz Guzik wrote: > > > > it fails to build for me: > > > > /usr/src/lib/libc/stdlib/snmalloc/malloc.cc:35:10: fatal error: > > 'override/jemalloc_compat.cc' file not found > > #include "override/jemalloc_compat.cc" > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 1 error generated. > > --- malloc.o --- > > *** [malloc.o] Error code 1 > > > > make[4]: stopped in /usr/src/lib/libc > > /usr/src/lib/libc/stdlib/snmalloc/memcpy.cc:25:10: fatal error: > > 'global/memcpy.h' file not found > > #include > > ^~~~~~~~~~~~~~~~~ > > 1 error generated. > > --- memcpy.o --- > > *** [memcpy.o] Error code 1 > > This looks as if you haven=E2=80=99t got the submodule? Is there anythin= g in > contrib/snmalloc? > And that is why we can't just start using submodules. They are not automatically used. People have to do different things that need to be publicized and well documented. And there are about a half a dozen decisions that need to be made about the details of their use, many of which have no clear obvious choice for the project. Without a good plan, clear comms and good docs it will be a support nightmare. Now please stop making these passive agressive comments about submodules. All they do is demotivate me to work on the plans to adopt them. There are a lot of details, many of which need to be play tested, before we can even get a plan to adopt. The snarky comments are why I quit working on things a year ago... they don't move the ball forward and just piss people off... Warner > this is a fresh world, top of snmalloc2 branch: > > commit a5c83c69817d03943b8be982dd815c7e263d1a83 > > Author: David Chisnall > > Date: Fri Jan 21 15:13:09 2022 +0000 > > > > Initial commit of snmalloc2 in libc. > > > > anyway, I wanted to say I find the memcpy thing incredibly suspicious. > > I found one article in > > > https://github.com/microsoft/snmalloc/blob/main/docs/security/GuardedMemc= py.md > > which benches it and that made it even more suspicious. How did the > > benched memcpy look like inside? > > Perhaps you could share what you are suspicious about? I don=E2=80=99t r= eally > know how to respond to something so vague. The document you linked to ha= s > the benchmark that we used (though the graphs in it appear to be based on > an older version of the memcpy). The PR that added PowerPC tuning has so= me > additional graphs of measurements. > > If you compile the memcpy file, you can see the assembly. The C++ > provides a set of building blocks for producing efficient memcpy > implementations. The fastest on x86 is roughly: > > - A jump table of power for small sizes that do power-of-two-sized small > copies (double-word, word, half-word, and byte) to perform the copy. > - A vectorised copy for medium-sized copies using a loop of SSE copies. > - rep movsb for large copies. > > The compiler does some quite complex layout for the jump table. > > David > > > --0000000000000fdb0105f449a32b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 9, 2023, 12:37 PM David Chisnall <theraven@freebsd.org> wrote:
<= /div>
On 9 Feb 2023, at 19:15, Mateusz Guzik = <mjguzik@gmail.com> wrote:
>
> it fails to build for me:
>
> /usr/src/lib/libc/stdlib/snmalloc/malloc.cc:35:10: fatal error:
> 'override/jemalloc_compat.cc' file not found
> #include "override/jemalloc_compat.cc"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1 error generated.
> --- malloc.o ---
> *** [malloc.o] Error code 1
>
> make[4]: stopped in /usr/src/lib/libc
> /usr/src/lib/libc/stdlib/snmalloc/memcpy.cc:25:10: fatal error:
> 'global/memcpy.h' file not found
> #include <global/memcpy.h>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~~~~~~~~~
> 1 error generated.
> --- memcpy.o ---
> *** [memcpy.o] Error code 1

This looks as if you haven=E2=80=99t got the submodule?=C2=A0 Is there anyt= hing in contrib/snmalloc?
And that is why we can't just start using subm= odules. They are not automatically used. People have to do different=C2=A0t= hings that need to be publicized and well documented. And there are about a= half a dozen decisions that need to be made about the details of their use= , many of which have no clear obvious choice for the project. Without a goo= d plan, clear comms and good docs it will be a support nightmare.=C2=A0

Now please stop making thes= e passive agressive comments about submodules. All they do is demotivate me= to work on the plans to adopt them. There are a lot of details, many of wh= ich need to be play tested, before we can even get a plan to adopt. The sna= rky comments are why I quit working on things a year ago... they don't = move the ball forward and just piss people off...
Warner=C2=A0

> this is a fresh world, top of snmalloc2 branch:
> commit a5c83c69817d03943b8be982dd815c7e263d1a83
> Author: David Chisnall <theraven@FreeBSD.org>
> Date:=C2=A0 =C2=A0Fri Jan 21 15:13:09 2022 +0000
>
>=C2=A0 =C2=A0 Initial commit of snmalloc2 in libc.
>
> anyway, I wanted to say I find the memcpy thing incredibly suspicious.=
> I found one article in
> https:= //github.com/microsoft/snmalloc/blob/main/docs/security/GuardedMemcpy.md
> which benches it and that made it even more suspicious. How did the > benched memcpy look like inside?

Perhaps you could share what you are suspicious about?=C2=A0 I don=E2=80=99= t really know how to respond to something so vague.=C2=A0 The document you = linked to has the benchmark that we used (though the graphs in it appear to= be based on an older version of the memcpy).=C2=A0 The PR that added Power= PC tuning has some additional graphs of measurements.

If you compile the memcpy file, you can see the assembly.=C2=A0 The C++ pro= vides a set of building blocks for producing efficient memcpy implementatio= ns.=C2=A0 The fastest on x86 is roughly:

=C2=A0- A jump table of power for small sizes that do power-of-two-sized sm= all copies (double-word, word, half-word, and byte) to perform the copy. =C2=A0- A vectorised copy for medium-sized copies using a loop of SSE copie= s.
=C2=A0- rep movsb for large copies.

The compiler does some quite complex layout for the jump table.

David


--0000000000000fdb0105f449a32b--