Date: Tue, 23 Apr 2024 10:37:01 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Alan Somers <asomers@freebsd.org> Cc: Karl Denninger <karl@denninger.net>, freebsd-hackers@freebsd.org Subject: Re: Stressing malloc(9) Message-ID: <2b72c4f749e93dfec08a164d5a664ee3@Leidinger.net> In-Reply-To: <CAOtMX2irXo_hvrhQhw0eLjCBiH7hZMTR9notBn9aDEMTynQiuQ@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_354318f0c1c8e56ac65f3fe01cb4c8cd Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-04-23 00:05, schrieb Alan Somers: > On Mon, Apr 22, 2024 at 2:07 PM Karl Denninger <karl@denninger.net> > wrote: >> >> On 4/22/2024 12:46, Alan Somers wrote: >> >> When I said "33kiB" I meant "33 pages", or 132 kB. And the solution >> turns out to be very easy. Since I'm using ZFS on top of geli, with >> the default recsize of 128kB, I'll just set >> vfs.zfs.vdev.aggregation_limit to 128 kB. That way geli will never >> need to allocate more than 128kB contiguously. ZFS doesn't even need >> those big allocations to be contiguous; it's just aggregating smaller >> operations to reduce disk IOPs. But aggregating up to 1MB (the >> default) is overkill; any rotating HDD should easily be able to max >> out its consecutive write IOPs with 128kB operation size. I'll add a >> read-only sysctl for g_eli_alloc_sz too. Thanks Mark. >> >> -Alan >> >> Setting this on one of my production machines that uses zfs behind >> geli drops the load average quite materially with zero impact on >> throughput that I can see (thus far.) I will run this for a while but >> it certainly doesn't appear to have any negatives associated with it >> and does appear to improve efficiency quite a bit. > > Great news! Also, FTR I should add that this advice only applies to > people who use HDDs. For SSDs zfs uses a different aggregation limit, > and the default value is already low enough. 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? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_354318f0c1c8e56ac65f3fe01cb4c8cd Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmYnczkACgkQEg2wmwP4 2IZnIhAAk5V4Y5SVbxQf3ackPNLDIvb3/rxDo0+UgYi+3mQKcqAbxv469Jis3JTr fr4b/lO8tBtI19M9uJLRlAkXPjcI3emf78H4wh2YpTTnveJAKuv2wWiNWe/r4J5e MEwIDOfzfY3SCY0wrhwaTMUOWuS4F4paWy1A1lVdYGEhLy3j1TptuP0ddL3D2SJT 5QrpGoLoERZ0EnddeBIEpILPBvNVSUkHT5JWvGfp2bk+Zgc3STR1TjPSTPsknLwv qI6PkCXEN+3Cub1XM2O2uFkLSRr50M1T/pLZX1k76En3PBGKc+LcglFoQ7CM901s y6uN70j3vy6k6lLGfVPcZ96cQ+3aRppUbCh7HV9FcNwkQH5sRUNrQHyloXTFaoXM ghPQVUnAk/JEMTRlbHwSgPr6/0U42OZ9DVVpdWWmzazN/pbU5cYZoBk1jG1R8CDK wKz1kutQbb/M4oenR0MVeky7GyJJdv4/GDcLr7o0rhy1UIIzwdCQAi3le7oKEqSL uApeTR9VSfm2WDem4FXXXZlbm9pOqGwT1waskf+4YTUI92VoOF1I9Z2REtbOdAJe QnSZqwFE00hEVI2/bOr4c8sUouqQLXArIeHi4S7/23O2+gg4BAY1vKtX+f+d+MRN O2X/NTQZINRXcHKN4Ei9LyciV0x02g5ixWYzkuVZBeDlrsAm8k0= =zKch -----END PGP SIGNATURE----- --=_354318f0c1c8e56ac65f3fe01cb4c8cd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2b72c4f749e93dfec08a164d5a664ee3>