From nobody Tue Sep 05 01:39:32 2023 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 4Rfp8k5h58z4rm6P for ; Tue, 5 Sep 2023 01:39:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rfp8k1yJJz3L24 for ; Tue, 5 Sep 2023 01:39:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693877987; bh=MLh2ZKkOcBMqd4kEA6M4JHaiI6Ys7B3oyWTj+C2aqWo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jQrFwqNQIJ4wILZor5uGUqGzAoQfygLoCnsUwln8YpeymXmyg59j9fJ+KFaEQNr3RP7g8AxnQQnXXf2SrvE2la4NgKcyfD62AUU5od12PExge+7zap3vgYA2lvBFkpS0zk3qbM9VAO7XHGU0hiGoO/IeR1W64WSfw6nJXWknIKyZaP4mrIBnBMDO7tE36JzOQYv4xsW4yyNjUqlq9PIx7Upal0AfaJKe2Wwg9trMMeTij2XVOMyi+bcVMB0vliYFp1T2SXXbyrL37qWoeWwGLISbnfB0qdli7MAbPEAVb72Gg9SRzND71DdKNDq0TpEkGYOHZN4OAL7W7y1QMpuEFA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693877987; bh=KtV55EkLgVb/DxBOEAOd5w/hn6wnQuAspon53etejXy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jUxf06VGGqIYFcoqr3X0C0n3akonwwXnOBhE9NaRqEttlqQw3N7A63NB6R1US9+5YIf7WgqmdGZ7GrnVIdxyUedpdkCpr5pcb2K7S3gY+bwg8nJB0XeEsUVlr5T37GRTBTXGikjUV/Aw/Lln2fI6qjhp6cWVweGmFjo15TPHzjGceG33bCrNndvv/D5BXVyLs+wqef4QRXTkOSWewKPbBPPxnvxnQ1aJSCNVK3TmtMeOoAYfxTWItoIzUkkKJ8r+QFq7EuePqhpfGvrV6yaMK1cbN2cDoc9vgIOZv27r/SC2juIlgMv4XSGN3GqY3UGje6x7wsyYkvgs2VH1738uIA== X-YMail-OSG: V.l2G2cVM1mfnHr3WApbIrbqKTcJYA3NWF0aohCuL3.6MR5FJKfdz8Fz5NL3O5R 8pkwrggOhckIKnnuJKXE3QjW67DQGrl1QLuzTaZuES0xuVTrzghITifUBwPd0eJBNjVUsFhK8dCI BtTZR5wSxfs3JK490PU9leUDWHGWHynRpV_AEB9Sf8DF7ONRtc4LXEm4l9qZ_kPH_VwYhQTZqug. PfEXQobAEVwOtOY_XDnINb2JwxMCBAXyqj00.L8BN9FChOQEgfck2qzQmTORGMd0GLsz2BS0D_8k NuG.7iJhVoThfypQePngm0CpEvn37tglnWegdIWBMC9B1wFuDXQ28Fdq3qss9nC4jgwFg5Jp89fo 9J9R0EXWMcVTZUDHktfp3KZUANgYZs.niMlzSZcFmnhbJmsrF8juuU6YIZPSDHVFMZ5uGmCmQ2hw T0y3QadZQC.L2eNDh8np8cUIm_5DtfPMZusrNqy4F3OcIVV.cGUYoPRMDK6DdkZjvxicjNL9XuKp dnpWrodUshFqfAxa1g3kb9ZXifwla5JwnxCo7NjQuvM.MgD3mjMtcWFF1796E6b4HgVhIiCW6sNg XlymjOMNdUgLmo40XXG4hDimoymsmVmhEVwr5kkDSSI1ZbNpe_wgxuT_M0gTIW9mg0Yy1CO_ikab 94FLTudvut01eDf6QwGSXhbE5HROTs4bMC9LkzM6_IoCigQ1nhhl_6FpKiNubiu.IgBhkCWj68f2 doVNyz.w7iP3vA7mZ7a.kgQZ2p2TsJy7PAUAxWdJlWdTC.MXpj2h1r7ZSAeBHVpC1YoRBRWcRL33 2M9ED3BIAFn6I8Zt6TsqIMeGbrjuNlgRoc5DMWAZXNWG_bHHxTwvIaDavd5YBFkHLHMaA4UH9EEC IxNsnIH_vz2jH14W_pIF0IFm56A62EqJgZSGMftnnwFOeoAWlcZMlgBXSu5Eknmzpd2ZvKEWXCX6 glqWx2SEz__RHMVT.ZNLybbR66b2Ccnd8e6RxZqyceP33gDJdE5J52zS.y6JHclQm8idJt9k4CJ9 zl..f3fUQjK.Pw9Pwrda31zQtQYEojZiAEgNCke8Jhjjfv_Z_kU3CtP2M2iyCTUh3STG_k6MVoSa bgsEJHob.Nv82mKKE2BK.aZbxInM7I0wNHaFRIRGlgbJyJGybv0Efdo1cjqSIig6FAZZKQaW6wd2 Zvn4Dl7SiTdimhK_wDFtMAQt5tjJ2CyIo9PMIypRJDr_BtIsTWq2kTnovtNN67keNeQUiuAEea9W pPHKE1Fo0rrYV1edyYpnGX0HOC29DEOxnksmGkzU9lMZ6vozWCori9uCWdDMpXTs1WONmEvCs6Qv eyZ2JPz9.2QjIFjIm7bKkTouM7jgiZhaq5QpBcfsf9T8ApPpgJj1o6TDt2XTkurDPRsMEFPK9skw i.IcSMjSEKaQDKGDsdULT.KT3ucOhWbwnOjELKdy6YYlc.i56ceH5ajFLWIs3qBcTuEQs5YynQfF WYJauy.T_jPWSTNSmgj88q3CHCNdGK353921Z8AxumgRW87bVf31a1FVQzx6nquW1mvgInY5X1_F tDCbOcWq0fsD9wEY7d_p3T52ifTSewUa8zlGKIdAle45armYb0m1C1oZKAGiIbO_Qs9rWuJ.aoS8 bAvvh2zbCPoXgWb0OLFWmUaZo_w2mPDAgE5R_bCpjerSgjhQdszLsUHAILvW9WNKwMfMf39MEUHG UpmTZY.KUViv6XVKfN5tx4VL4tIHNv2e__bJk3Rfg0.9bEYuDaCl8mmc5hlZwgYzygfe4Sde2Ytb tIEchAjPiZ6K8Df84e0_5_SPx.pmb3kJUHwDI1d9uzWQ9K.ZQInm2G8SUZHnAjk6_1j7yRfjxILy CyR3325VIl2P4MpUqlc4EjXHn_AVpWSwzana9uLle.aBJNHsTMjQNBOfHVGFuBcyTph_wZfaSjVS c7z27ImyaS3KvpBvxYRm638ggrJ9uYQV.YrNqV1LnkFO3ZkkIKL.3ofACewyxUgPM_t.j3nrtDSM YluaQhfq5DjFC7Aenx7Ww1LcTnTjh.511Yu9tppen17GEjgm0brF3M.Ru9v_oGdtKEweyTSxQWm6 EhWE0AocpCKftQcuHiqA3YbkpQLFyI.xoy9W0O3ytPGVV4Ze4vBvovnBty1Aukakwl.sY9hg9YJ4 n7hr2Es7z7lwM0PsE1WbrJ8DYv6rY_MaLEGDWSfvzdJqFvY87TLMbdXMZG0QXG9tL7Q77nZX66Zi kJEV12gxaosHe8xo6TxqqOHCxvfIoLMZpYdtF_LSbAfLZZhw2L3veC35C6KwgF89Pvi88hDy2cM9 6 X-Sonic-MF: X-Sonic-ID: 2f556f5f-1f8b-4d44-b6ab-39b2b07d5ab8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Sep 2023 01:39:47 +0000 Received: by hermes--production-gq1-6b7c87dcf5-6x8bf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 801c3bf5026c7120c3c60bafe3edf13c; Tue, 05 Sep 2023 01:39:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 \(3731.700.6\)) Subject: Re: An attempted test of main's "git: 2ad756a6bbb3" "merge openzfs/zfs@95f71c019" that did not go as planned From: Mark Millard In-Reply-To: <5605506b-5059-fb72-3e5a-741863d54444@FreeBSD.org> Date: Mon, 4 Sep 2023 18:39:32 -0700 Cc: dev-commits-src-main@freebsd.org, Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: <5724006A-F4C4-42CA-98A9-90C5EB914F5E@yahoo.com> References: <673A446E-6F94-451E-910F-079F678C5289@yahoo.com> <2BDD30B5-6248-4EC3-83C8-0499E0717D1D@yahoo.com> <69028684-c2cd-8f0c-617f-d0763c08dbe4@FreeBSD.org> <8D832756-6754-4D1E-AE8D-E716FE08F747@yahoo.com> <5605506b-5059-fb72-3e5a-741863d54444@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4Rfp8k1yJJz3L24 On Sep 4, 2023, at 10:05, Alexander Motin wrote: > On 04.09.2023 11:45, Mark Millard wrote: >> On Sep 4, 2023, at 06:09, Alexander Motin wrote: >>> per_txg_dirty_frees_percent is directly related to the delete delays = we see here. You are forcing ZFS to commit transactions each 5% of = dirty ARC limit, which is 5% of 10% or memory size. I haven't looked on = that code recently, but I guess setting it too low can make ZFS commit = transactions too often, increasing write inflation for the underlying = storage. I would propose you to restore the default and try again. >> While this machine is different, the original problem was worse than >> the issue here: the load average was less than 1 for the most part >> the parallel bulk build when 30 was used. The fraction of time = waiting >> was much longer than with 5. If I understand right, both too high and >> too low for a type of context can lead to increased elapsed time and >> getting it set to a near optimal is a non-obvious exploration. >=20 > IIRC this limit was modified several times since originally = implemented. May be it could benefit from another look, if default 30% = is not good. It would be good if generic ZFS issues like this were = reported to OpenZFS upstream to be visible to a wider public. = Unfortunately I have several other project I must work on, so if it is = not a regression I can't promise I'll take it right now, so anybody else = is welcome. As I understand, there are contexts were 5 is inappropriate and 30 works fairly well: no good single answer as to what value range will avoid problems. >> An overall point for the goal of my activity is: what makes a >> good test context for checking if ZFS is again safe to use? >> May be other tradeoffs make, say, 4 hardware threads more >> reasonable than 32. >=20 > Thank you for your testing. The best test is one that nobody else = run. It also correlates with the topic of "safe to use", which also = depends on what it is used for. :) Looks like use of a M.2 Samsung SSD 960 PRO 1TB with a non-debug FreeBSD build is suitable for the bulk -a -J128 test (no ALLOW_MAKE_JOBS variants enabled, USE_TMPFS=3Dno in use) on the 32 hardware thread system. (The swap partition in use is from the normal environment's PCIe Optane media.) The %idle and the load averages and %user stayed reasonable in a preliminary test. One thing it does introduce is trim management (both available and potentially useful). (Optane media does not support or need it.) No per_txg_dirty_frees_percent adjustment involved (still 5). I've learned to not use ^T for fear of /bin/sh aborting and messing up poudriere's context. So I now monitor with: # poudriere status -b in a separate ssh session. I'll note that I doubt I'd try for a complete bulk -a . I'd probably stop it if I notice that the number of active builders drops off for a notable time (normal waiting for prerequisites appearing to be why). =3D=3D=3D Mark Millard marklmi at yahoo.com