Date: Tue, 23 Apr 2024 15:58:53 -0600 From: Warner Losh <imp@bsdimp.com> To: Alexander Leidinger <Alexander@leidinger.net> Cc: Alan Somers <asomers@freebsd.org>, Karl Denninger <karl@denninger.net>, freebsd-hackers@freebsd.org Subject: Re: Stressing malloc(9) Message-ID: <CANCZdfqACh-3v6eA5_rAswe0bJ86GukaXRfMFi6k7NKZZEwAvw@mail.gmail.com> In-Reply-To: <5abe7eb5b80ab164b91c858bfd8121d7@Leidinger.net> References: <CAOtMX2jeDHS15bGgzD89AOAd1SzS_=FikorkCdv9-eAxCZ2P5w@mail.gmail.com> <ZiPaFw0q17RGE7cS@nuc> <CAOtMX2jk6%2BSvqMP7Cbmdk0KQCFZ34yWuir7n_8ewZYJF2MwPSg@mail.gmail.com> <ZiU6IZ29syVsg61p@nuc> <CAOtMX2j=yaYeE%2B-fycg2mRRC_Jb9p74cn_dcenhH2xRRxz1shg@mail.gmail.com> <CAOtMX2hDfX-T90x9Fb2Wh%2BvgLvw9fUGmaDxh-FWaYwBTPwFY6Q@mail.gmail.com> <b1e56d20-dc98-4fff-adec-3f8cfae26c05@denninger.net> <CAOtMX2irXo_hvrhQhw0eLjCBiH7hZMTR9notBn9aDEMTynQiuQ@mail.gmail.com> <2b72c4f749e93dfec08a164d5a664ee3@Leidinger.net> <CAOtMX2jnNvnZBe7UdktQggsEQO%2BfovA-g_=-fZtbhH=caSLksQ@mail.gmail.com> <5abe7eb5b80ab164b91c858bfd8121d7@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000a882910616caa977 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 23, 2024 at 7:30=E2=80=AFAM Alexander Leidinger <Alexander@leid= inger.net> wrote: > Am 2024-04-23 14:47, schrieb Alan Somers: > > On Tue, Apr 23, 2024 at 2:37=E2=80=AFAM Alexander Leidinger > > <Alexander@leidinger.net> wrote: > > >> You basically say, that it is not uncommon to have such large > >> allocations with kernels we ship (even in releases). > >> Wouldn't it make sense to optimize the kernel to handle larger uma > >> allocations? > >> > >> Or do you expect it to be specific to ZFS and it may be more sane to > >> discuss with the OpenZFS developers to reduce this default setting? > > > > Yes, both of those things are true. It might make sense to reduce the > > setting's default value. OTOH, the current value is probably fine for > > people who don't use geli (and possibly other transforms that require > > allocating data). And it would also be good to optimize the kernel to > > perform these allocations more efficiently. My best idea is to teach > > g_eli_alloc_data how to allocate scatter/gather lists of 64k buffers > > instead of contiguous memory. The memory doesn't need to be > > contiguous, after all. But that's a bigger change, and I don't know > > that I have the time for it right now. > > -Alan > > Do you have time do make a nice description of what would have to be > done in the wiki? > https://wiki.freebsd.org/IdeasPage I've added the super-brief verrsion to https://wiki.freebsd.org/WarnerLosh which has my crazy ideas list... Warner --000000000000a882910616caa977 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 23, 2024 at 7:30=E2=80=AF= AM Alexander Leidinger <<a href=3D"mailto:Alexander@leidinger.net">Alexa= nder@leidinger.net</a>> wrote:<br></div><blockquote class=3D"gmail_quote= " style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= padding-left:1ex">Am 2024-04-23 14:47, schrieb Alan Somers:<br> > On Tue, Apr 23, 2024 at 2:37=E2=80=AFAM Alexander Leidinger<br> > <<a href=3D"mailto:Alexander@leidinger.net" target=3D"_blank">Alexa= nder@leidinger.net</a>> wrote:<br> <br> >> You basically say, that it is not uncommon to have such large<br> >> allocations with kernels we ship (even in releases).<br> >> Wouldn't it make sense to optimize the kernel to handle larger= uma<br> >> allocations?<br> >> <br> >> Or do you expect it to be specific to ZFS and it may be more sane = to<br> >> discuss with the OpenZFS developers to reduce this default setting= ?<br> > <br> > Yes, both of those things are true.=C2=A0 It might make sense to reduc= e the<br> > setting's default value.=C2=A0 OTOH, the current value is probably= fine for<br> > people who don't use geli (and possibly other transforms that requ= ire<br> > allocating data).=C2=A0 And it would also be good to optimize the kern= el to<br> > perform these allocations more efficiently.=C2=A0 My best idea is to t= each<br> > g_eli_alloc_data how to allocate scatter/gather lists of 64k buffers<b= r> > instead of contiguous memory.=C2=A0 The memory doesn't need to be<= br> > contiguous, after all.=C2=A0 But that's a bigger change, and I don= 't know<br> > that I have the time for it right now.<br> > -Alan<br> <br> Do you have time do make a nice description of what would have to be <br> done in the wiki?<br> =C2=A0 =C2=A0 =C2=A0<a href=3D"https://wiki.freebsd.org/IdeasPage" rel=3D"n= oreferrer" target=3D"_blank">https://wiki.freebsd.org/IdeasPage</a></blockq= uote><div><br></div><div>I've added the super-brief verrsion to=C2=A0<a= href=3D"https://wiki.freebsd.org/WarnerLosh">https://wiki.freebsd.org/Warn= erLosh</a> which has my crazy ideas list...=C2=A0</div><div><br></div><div>= Warner</div></div></div> --000000000000a882910616caa977--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqACh-3v6eA5_rAswe0bJ86GukaXRfMFi6k7NKZZEwAvw>