From nobody Sun Dec 1 07:05:01 2024 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 4Y1Hx61z0Mz5f991 for ; Sun, 01 Dec 2024 07:05:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y1Hx52ZyYz4d4Q for ; Sun, 1 Dec 2024 07:05:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=jvzUCVGL; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::1032) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2ee69fc0507so1327179a91.0 for ; Sat, 30 Nov 2024 23:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1733036712; x=1733641512; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=H1az5Ie/BvoA3FcOmxV8amiFs09HuKhYuHHSE+ItXc0=; b=jvzUCVGLDqmvyNj+R/rxESvpnbRNxhywzgHF8fAiEnrpSlhLTLkpHY5j6GvQXQRzBo 78+F1nHcxJlnh4ybiVjXe0UYwd0DbYpNIsIYv+YasgpCx8ixe0Gsz9GkiJkvaGIke8Xn uOTKez1guTcrr1tCdQzVzGAibUhlcgcw3DGSv/quxQAiwGTRrT3sJzcUBlyAjy8g3KDo 5jIkZtsWHi4FVJPWCR0tLgCBsRRfeh2ijbmzo0uaSbUBEHhBSLP/O7VJCioHp1fehmg8 WYeI3qVPJZ9pJvyht502jFKa+i2sNHJ31qHrukKUsewbS8Rm+0A0W2t/+1KbaWXZOpJk qXKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733036712; x=1733641512; 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=H1az5Ie/BvoA3FcOmxV8amiFs09HuKhYuHHSE+ItXc0=; b=vj+RXtc0eraPXWIlPZhwT1cXxnswQ16ZhbM8wbjDsleXFn3wTzfo8nby45v7UnTZWE 3O/NzLjyFbcOUi8zTmkhEAU2HiwpeqElCdYR/R2SYZqudZJY1TuQd8TdrKjtP5vvFqQq HHCGWXw2J1lmRpZ7l5IQBF4WNTyBfzVjk65B/Zg8r/0WEbcYCxouDj/M4m1uNc8Aqg06 n458o9/FGQD3w4sTvBS5cLldAq+jcciAjA2wpmlaOygNmsb3Tv7oyyf6NVEEz1kIugyX pCiWUFO0IZWyoQsrVmTb3loZrFWd8a/ZqUSzF/7Q5C/2RP9Xxtzr1tWHTKAbrlDZf8mi hZVw== X-Forwarded-Encrypted: i=1; AJvYcCXLFVm3k3NAiCQ3f02MW2XVI0CXVtI+/S8T+Ky3hKMrlLKesV1AZbSnAp6b+BpnvWyB9rupvMxw1/U/G75ARFY=@freebsd.org X-Gm-Message-State: AOJu0Yz5xCSigRMRWPXWJuwRE0slPbfj1cIn8hz/0u9K9gORbSg3wNkH iaH35lo3iVXjL6RsxHlmUziTeHKmSfpR9MCQnDz0rmihA7XG5m17hZ0xwzGCt1Is3v/+6MkqUMu 7ta+B1zOlyZO6arniwQD01KWclu8wwOwyP5zP1kyf+fM/JYLrEmA= X-Gm-Gg: ASbGncsbRYMda/PVCW/C9w5HWlPBPjTmzg2e7LDfVTnJ3tbOm3U+bQQ5tivPjNq8OaB HLho9HNe7Il0iDezj8gh+iRoU+my6RERIjwQL8rIyufESu++VO2ht1pE5ucwLcg== X-Google-Smtp-Source: AGHT+IE4FMgOXD4KVZb335xDvBFrvJzmCXf8TUSQ6w/pKcKI5EhYZaXMCpeQX0oTbmDlq9tRTcNuEH7GM3V4WXlFZgU= X-Received: by 2002:a17:90b:548f:b0:2ea:b564:4b31 with SMTP id 98e67ed59e1d1-2ee08eb7ca7mr23003563a91.19.1733036711763; Sat, 30 Nov 2024 23:05:11 -0800 (PST) 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 References: In-Reply-To: From: Warner Losh Date: Sun, 1 Dec 2024 00:05:01 -0700 Message-ID: Subject: Re: Long time outdated jemalloc To: Minsoo Choo Cc: cglogic , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000967b870628300dde" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1032:from]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[protonmail.com,freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4Y1Hx52ZyYz4d4Q X-Spamd-Bar: -- --000000000000967b870628300dde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (sorry to follow up to my own email and topposting) I got the vendor branch bootstrapped: I created vendor/jemalloc and tagged vendor/jemalloc/5.2.1, and created a merge commit from that branch to main. I had to tweak the FREEBSD-Xlist a little.I've not updated the other two FREEBSD-* files, but the steps were documented in the commit messages (the vendor branch one is especially long and likely should migrate into the developer handbook). FREEBSD-update is basically a shell script to do the same thing that git subtree merge does, though I'm sure some tweaks could help the next time (if there is a next time, jemalloc upstream seems to have slowed way down of late). Next up,I'll create 5.3.0 import on the vendor branch, do the merge and start testing (it will be Minsoo's pull request, rebased, with any conflicts resolved and merge commit recorded). But that will have to be tomorrow or more likely during the work week. I'm too tired tonight to get it right at the moment. And a special thanks to emaste for giving bz the right recipe for doing the subtree merge w/o git subtree for his work on the linux wifi drivers in the tree. Warner On Sat, Nov 30, 2024 at 9:38=E2=80=AFPM Warner Losh wrote: > Yea, I need to get a copy of jemalloc 5.3.0 and 5.2.1 to try to > 'bootstrap' the vendor branch. > Then I need to bootstrap it... > > I just did the same with edk2 (which had a vendor branch, but hadn't been > updated since svn times). > However, jemalloc doesn't have a vendor branch yet, so I'll have to creat= e > that, but I'll start with the > current version rather than doing full history... So I'll start there. > I also just did awk and lua, so once I have things bootstrapped, I'll be > able to add 5.3.0 and then layer Minsoo's on > top of that and then start testing it somehow. > > Malloc makes me nervous to touch, honestly, but I'll give it a go and tes= t > boot on my system and > maybe see if we can survive a workload at work w/o regressions... But I > can't do a full test with lots > of machines until after the first of the year (though I can do a couple > for a few days before then). > > So my next step is to bootstrap the vendor branch... I'll give that a try > tonight. > > Warner > > On Sat, Nov 30, 2024 at 8:26=E2=80=AFPM Minsoo Choo > wrote: > >> I have already submitted PR on github ( >> https://github.com/freebsd/freebsd-src/pull/1337) and phabricator ( >> https://reviews.freebsd.org/D41421). I don't have access (commit bit) to >> freebsd git repo, so there is nothing I can do at this point since vendo= r >> import and landing patches requires commit bit. >> On Saturday, November 30th, 2024 at 1:42 PM, cglogic < >> cglogic@protonmail.com> wrote: >> >> I see, it happens. >> Maybe another committer will volunteer to do the update. >> I hope it will make its way into 15.0 release. >> >> Thanks. >> On Friday, November 29th, 2024 at 9:38 PM, Warner Losh >> wrote: >> >> I've been swamped. we need to bootstrap the vendor branch, and the way >> prior updates were done >> isn't so great. >> >> Warner >> >> On Mon, Nov 25, 2024 at 2:21=E2=80=AFAM cglogic = wrote: >> >>> Hello guys, >>> >>> How the update of jemalloc is going? It's November now. >>> >>> Thanks. >>> On Monday, July 22nd, 2024 at 7:02 PM, Minsoo Choo < >>> minsoochoo0122@proton.me> wrote: >>> >>> First, sorry for late response. >>> >>> cglogic, thank you for bringing up this issue again since I nearly >>> forgot that this issue was still open. >>> >>> Warner, as I can't access to my FreeBSD instance until the end of >>> August, but I can still edit and push the code through my Arm Mac. This >>> means that I can't test the updated code on my machine, but I can join = the >>> review process and listen to change proposals. >>> >>> I'll open a Github PR in a few hours. (The phabricator review will stay >>> opened just in case) >>> On Monday, July 22nd, 2024 at 5:08 AM, Warner Losh >>> wrote: >>> >>> >>> >>> On Sun, Jul 21, 2024 at 2:03=E2=80=AFPM cglogic wrote: >>> >>>> >>>> On Sunday, July 21st, 2024 at 6:54 AM, Warner Losh >>>> wrote: >>>> >>>> >>>> >>>> On Sat, Jul 20, 2024 at 1:59=E2=80=AFAM cglogic wrote: >>>> >>>>> Hello FreeBSD community, >>>>> >>>>> After Jason Evans stepped aside from maintaining jemalloc in FreeBSD, >>>>> it's not updating in time anymore. >>>>> Version 5.3.0 was released May 6, 2022 and FreeBSD still not imported >>>>> it into the tree. >>>>> >>>>> There is a pending review https://reviews.freebsd.org/D41421 from Aug >>>>> 11, 2023. >>>>> I'm successfully running FreeBSD/amd64 system with D41421 applied for >>>>> 8 months, as well as many other people. >>>>> >>>>> Can it be reviewed and committed to CURRENT? >>>>> Or, if there is no committers willing to do it, can commit bit be >>>>> given to submitter or another person willing to do this? >>>>> >>>>> It's very disappointing when users spend their time to fill such gaps >>>>> and their efforts just ignored by the developers. >>>>> Every year FreeBSD Community Survey asking about user experience in >>>>> contributing to FreeBSD. >>>>> Here you can see an example of such contributing. >>>>> >>>>> >>>> First, thank you for being persistent and continuing to bring it up. >>>> It's important to do that to make sure this (and your many other) >>>> contribution doesn't fall on the floor. >>>> >>>> And to be fair, we're only 3 months since the last update. Still, quit= e >>>> a bit longer than you should have to wait, but not nearly the year the >>>> original date suggests. >>>> >>>> And this is a perfect storm of "how the project is bad at accepting >>>> contributions": >>>> (1) The original submission was close to the 14 branch creation time. >>>> This meant that we weren't well prepared to look at it since it is suc= h an >>>> invasive change (at least on its surface). It also slowed the initial >>>> response... >>>> (2) There was a number of back and forth requests for changes, which >>>> took time to sort out... >>>> (3) The size of this is huge, well beyond the capacity of Phabricator >>>> to review accurately... >>>> (4) It's a vendor import. That means we can't just drop the Phabricato= r >>>> review into the tree... >>>> (5) It's phabricator: this is a great tool for developers, but we have >>>> a terrible track record of using it for intake from new contributors. = We >>>> don't have any oversight at all over this tool, at there's at best tep= id >>>> and luke warm attempts to look for drop balls. >>>> >>>> All of these things are a terrible experience. I can only apologize. >>>> These days, we might steer this towards github, but the 'vendor import= ' >>>> means you really need someone on the inside, or you need to be on the >>>> inside to make that work. >>>> >>>> So, how to move forward? Well, I'd like to propose the following: >>>> (1) submit all the other Phabricator reviews you have open (they are >>>> mostly good, or close to good) to github. Github is being actively man= aged >>>> and will make it faster to get things it. It's a much better tool for = new >>>> contributors (and even frequent contributors of smallish things). >>>> (2) I should do an vendor import of 5.3.0 from github, and do the merg= e >>>> to a branch and push that to github. You can then layer on your change= s and >>>> those can be reviewed more closely as a pull request against the branc= h I >>>> push. I suspect that most of the issues are sorted out already >>>> (3) I'll land it via that route... >>>> >>>> And, if the sum of the other pull requests and this are good (and I >>>> suspect they will be), then we can talk about commit bits and such. >>>> >>>> It's experiences like this which is why I'm trying to stand up github >>>> pull requests as a reliable way to get things and and the best place t= o >>>> send people... >>>> >>>> Thanks again for persisting, and also for expressing this criticism >>>> that we (hopefully) can use to make it better. >>>> >>>> Warner >>>> >>>> >>>> Hello. >>>> >>>> I'm not the author of D41421. Just applied the patch to test it 8 >>>> months ago. And recently discovered that it's still not committed. >>>> I can't copy your message to Phabricator because don't have an account= . Please, >>>> if you have time, help the author in D41421. >>>> >>> >>> Ah yes. I've been in touch with the author for other things, and someho= w >>> thought it was you.... I'll reach out to him via other means... >>> >>> Warner >>> >>> >>> >>> >> >> --000000000000967b870628300dde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(sorry to follow up=C2=A0to my own email = and topposting)

I got the vendor branc= h bootstrapped: I created vendor/jemalloc and tagged vendor/jemalloc/5.2.1,=
and created a merge commit from that branch=C2=A0to main. I had = to tweak the
FREEBSD-Xlist a little.I've not updated the othe= r two FREEBSD-* files, but the steps were
documented in the commi= t messages (the vendor branch one is especially long and
likely s= hould migrate into the developer handbook). FREEBSD-update is basically
a shell script to do the same thing that git subtree merge does, tho= ugh I'm sure some
tweaks could help the next time (if there i= s a next time, jemalloc upstream seems to
have slowed way down of= late).

Next up,I'll create 5.3.0 import on th= e vendor branch, do the=C2=A0merge and start testing (it will be
= Minsoo's pull request, rebased, with any conflicts resolved and merge c= ommit recorded).
But that will have to be tomorrow or more likely= during the work week. I'm too tired tonight
to get it right = at the moment.

And a special thanks to emaste for = giving bz the right recipe for doing the subtree merge
w/o git su= btree for his work on the linux wifi drivers in the tree.

Warner

On Sat, Nov 30, 2024 at 9:38=E2=80=AFPM= Warner Losh <imp@bsdimp.com> w= rote:
Yea, I need to get a copy of jemalloc 5.3.0 and 5.2.1 to try to &#= 39;bootstrap' the vendor branch.
Then I need to bootstrap it...

I just did the same with edk2 (which had a vendor bra= nch, but hadn't been updated since svn times).
However, jemal= loc doesn't have a vendor branch yet, so I'll have to create that, = but I'll start with the
current version rather than doing ful= l history...=C2=A0 So I'll start there.
I also just did awk a= nd lua, so once I have things bootstrapped, I'll be able to add 5.3.0 a= nd then layer Minsoo's=C2=A0 on
top of that and then start te= sting it somehow.

Malloc makes me nervous to touch= , honestly, but I'll give it a go and test boot on my system and
<= div>maybe see if we can survive a workload at work w/o regressions... But I= can't do a full test with lots
of machines until after t= he first of the year (though I can do a couple for a few days before then).=

So my next step is to bootstrap the vendor branch= ... I'll give that a try tonight.

Warner
=

= On Sat, Nov 30, 2024 at 8:26=E2=80=AFPM Minsoo Choo <minsoochoo0122@proton.me>= wrote:
I have already submitted PR on github (https://github.com/freebsd/freebsd-sr= c/pull/1337) and phabricator (h= ttps://reviews.freebsd.org/D41421). I don't have access (com= mit bit) to freebsd git repo, so there is nothing I can do at this point si= nce vendor import and landing patches requires commit bit.
On Friday, November 29th, 2024 at 9:38 PM, Warner Losh <imp@bsdimp.com> wrote:<= br>
I've been swamped. we need to bootstrap th= e vendor branch, and the way prior updates were done
isn't so great= .

Warner

On Mon, Nov 25, 2024 at 2:21=E2=80= =AFAM cglogic <cglogic@protonmail.com> wrot= e:
Hello guys,

How the update of jemalloc is go= ing? It's November now.

Thanks.
On Monday, July 22nd, 2024 at 7:02 PM, Minsoo Choo <minsoochoo0122@proton.me> wrote:
Firs= t, sorry for late response.

cglogic, thank you for bringing up this issue again since I near= ly forgot that this issue was still open.

Warner, as I can't access to my FreeBSD instan= ce until the end of August, but I can still edit and push the code through = my Arm Mac. This means that I can't test the updated code on my machine= , but I can join the review process and listen to change proposals.

I'll open a Github P= R in a few hours. (The phabricator review will stay opened just in case)
On Monday, July 22nd, 2024 at 5:08 AM, Warner Losh <imp@bsdimp.com> wrote:


On Sun, Jul 21, 2024 at 2= :03=E2=80=AFPM cglogic <cglogic@protonmail.com= > wrote:

On Sunday, July 21st, 2024 at 6:54 AM, Warner Losh <imp@bsdimp.com> wrote:


On Sat, Jul 20, 2024 at 1= :59=E2=80=AFAM cglogic <cglogic@protonmail.com= > wrote:
Hello FreeBSD community,

After Jason Evans stepped aside from = maintaining jemalloc in FreeBSD, it's not updating in time anymore.
Version 5.3.0 was released = May 6, 2022 and FreeBSD still not imported it into the tree.

There is a pending review https://reviews.freebsd.org/D41421 from Aug 11, 2023.
I'm succes= sfully running FreeBSD/amd64 system with D41421 applied for 8 months, as we= ll as many other people.

= Can it be reviewed and committed to CURRENT?
Or, if there is no committe= rs willing to do it, can commit bit be given to submitter or another person= willing to do this?
=
It's very disappointing when users spend their time to fi= ll such gaps and their efforts just ignored by the developers.
Every year FreeBSD Community Survey asking about user experience in contr= ibuting to FreeBSD.
Here you can see an example of su= ch contributing.


Firs= t, thank you for being persistent and continuing to bring it up. It's i= mportant to do that to make sure this (and your many other) contribution do= esn't fall on the floor.

And to be fair, w= e're only 3 months since the last update. Still, quite a bit longer tha= n you should have to wait, but not nearly the year the original date sugges= ts.

And this is a perfect storm of "how t= he project is bad at accepting contributions":
(1) The origi= nal submission was close to the 14 branch creation time. This meant that we= weren't well prepared to look at it since it is such an invasive chang= e (at least on its surface). It also slowed the initial response...
(2) There was a number of back and forth requests for changes, which= took time to sort out...
(3) The size of this is huge, well beyo= nd the capacity of Phabricator to review accurately...
(4) It'= ;s a vendor import. That means we can't just drop the Phabricator revie= w into the tree...
(5) It's phabricator: this is a great tool= for developers, but we have a terrible track record of using it for intake= from new contributors. We don't have any oversight at all over this to= ol, at there's at best tepid and luke warm attempts to look for drop ba= lls.

All of these things are a terrible experience= . I can only apologize. These days, we might steer this towards github, but= the 'vendor import' means you really need someone on the inside, o= r you need to be on the inside to make that work.

= So, how to move forward? Well, I'd like to propose the following:
=
(1) submit all the other Phabricator reviews you have open (they are m= ostly good, or close to good) to github. Github is being actively managed a= nd will make it faster to get things it. It's a much better tool for ne= w contributors (and even frequent contributors of smallish things).
(2) I should do an vendor import of 5.3.0 from github, and do the merge = to a branch and push that to github. You can then layer on your changes and= those can be reviewed more closely as a pull request against the branch I = push. I suspect that most of the issues are sorted out already
(3) I'll land it via that route...

And, if = the sum of the other pull requests and this are good (and I suspect they wi= ll be), then we can talk about commit bits and such.

It's experiences like this which is why I'm trying to stand up g= ithub pull requests as a reliable way to get things and and the best place = to send people...

Thanks again for persistin= g, and also for expressing this criticism that we (hopefully) can use to ma= ke it better.

Warner

Hello.

I'm not the author of = D41421. Just applied the patch to test it 8 months ago. And recently = discovered that it's still not committed.
I can't copy your message to Phabricator becaus= e don't have an account. Please, if you have time, help the auth= or in D41421.

Ah yes. I've been i= n touch with the author for other things, and somehow thought it was you...= . I'll reach out to him via other means...

Wa= rner




--000000000000967b870628300dde--