From nobody Fri Dec 22 20:08:22 2023 X-Original-To: freebsd-fs@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 4SxdfK3536z54PfJ for ; Fri, 22 Dec 2023 20:08:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (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 4SxdfH3msyz4L6v for ; Fri, 22 Dec 2023 20:08:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=UFyXLAaa; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703275717; bh=E0DZVRPyWK+mKovpB+oteHHIrMQlEewyD/ibsXPbEO0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=UFyXLAaaNcq0qxN4d/6JY1h+a8zbZdfObXosY6Sn0nCrVr1dvpp2At6vTpLDqDanYAqceyrEzkhG3jOPMx3ncscXcTFRQnlfk4fbJzs1fASN+bNp8dDgPx9vcY/oFV93nYwHZm7/qVm//lKcPSwgw/I1dvc2KVlc4bPGHuvYE78OA0f6AkmhOvW3xAhCAi5yAHVAQhXOOx5G+niQ3g6kjcMKwjyqGBT6Nh9mtM/UmEOCf/yW6UJyM64hykMXKAEu+QrjLKoiBkEBw+qoKC3Ws+y9C14wyQQZfYRRfkRf4cFmTEGaS9XbebdvrLDMG1ftmKxn3ffCbaf4pTyICpZMTg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703275717; bh=JE0gH2JMy4yk2ZPUuv0wTiaRQpTVLP1DzlSxjnEePOR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Cdc3bbgZ3t6hWz6yfo0ngsJkggCYpSCbWnLQRvyi9xfpprKeJgU2GJwtBTAIwtarbHinJesVEQzaYsYFEiIX9JgvCuqgo4R4WaYcYnkbwwp2Knf9ShlPQDpkBJeAUvUUDm9dYmQxe2UecJrC6DHire77+vfcdJl1Eho/eq90aIiq5oo9bXVujIrHl9EhruZ5ftA6H+a/dJc1B0ukPRvQ3XLZOszbbeeG+XOhEiMWRr+vVdpBzoWaOLSHiM0H+1jY8iLzIdJL49kqifAAm8zCkckJ/uJRwBCpAQgQ9JLDU2TSg6rCQPizetGHrNHe+mN3d4zmv5bnjAp6vpG6HmL6jg== X-YMail-OSG: rySN3MwVM1mJxSLjTgd159y9EA0B78eo_1m5mwJ75Vq0k0NOhN67CtVcTMR910Q sCYJPZD_Em8q_VjlQmrdZFZtfckMfSR7_FFQkJKUd0.sbz2zXAQhvP665CqbBuZxSON.YGV5zqKi 62GE.z1V5DO8AtsJ0JnZxnWa8JXCRjDGg_2g4x1MhTxSkRPqHInnE5PwLdrmB..p.YSzrIwApQHb LPlacQgo7O3QF33xJbbs7CFviRODKeFGwrWj2YnzFNr8v_9PHQufRZ52V.dpOoLxb3PqO1OnS5jR Lm5wPvqOfJs4w3Kv6KF2qXBCtCqA6zdBWOzO30qjSpKyQm3ND8ife6hkU.nWjGQyAIipXa1UFfka oEzbhLWpFWEHU.9ZcYunoRwBP57dKxh.EWdxq4j6tI.BWGx6LWx5jDwy8kNl_fNeVF1SVLX9F7Iy elIKByhElQXsghFev0IYR58D2u4frmEseQ1xJK9ibP2TfBweMVZb2ouvYy7upxWMtFizSZfwV8qb PBFaTFDVZnh3GtGTYEYnL5SjQetHI5CgLKeBKfa75oFLjX6F5Zkr.6huX46dpaySRJuGa_f1GgWs B5zFFfRrRyB8gbPZyrITluQyu31khb6OVt8fRE4KN58lcZZ02Z4rNjW3aNfBkdeWG2i7LdV6o.8q ipAVPc9sJ_9mkvIA6h365aDRM8LUPnssSLOSKSimfDJeL_nJ0qOZYH0ZyL0qgHJbsXribEJomHjF zZjQKzDJhFlvv2AR4NI0TO_LYlbXoe9IoZt2ExqeryEaxglz0f.GofExh.IfdlNCsKTUabuOAAKu cjG0EyPC7wfdc7C_JNfGuRNBkRRFS5dcLDd4KdeYkkEn8Ny00c_jizcFakvtIBTLvQCXUTLUjvDG mt2ToXRqnGqz.kCplAW1qmNmeK31gPPk1MN8ko36uzMkZiHHCcDy_mq.2cOE45mGV5k0npTuo5W3 bnCEYq6bSUPdU6oz.enQq9G1f17V4J.LkZ.QkN_kwCi7Fg.Arv7.hnc7mspjmzQeCkEobJFVWdx2 v5E8oVDqjMu1T1xVjJHSuYPXlQBg8kChBGZGuoIlfDg5ND6bX3mkTI9j_Vh4Ca8rows.V8iyH4NA CFFK4XIWRF60TKMHd89cqXhZ3B_XDtX7H9gC_udnTtQWI0FDOVGs3strtPo.zWyiW__BFgIjnH2D 0WJjqFIBuUXd74V.y8UKJwHM3mGSZeJWA.c7gHb2XjVgYE0PyPhuUltV0T39bHjJ9DXx7z2mzAle t6zGXNjr4rTUL8u5_H9.CMUQNSxp3UKotvWKzxZGOXMEmMZfqd_7l9CgnY00fnWQmTe_uffWovEY Wl0VOcb59YRjAQHk67ZcxLWD.Ebpz1zdcWQs44aJDrJsYHVTR2CjhloBr0_T6d0Zp4g0gOJsebIh c33.bENor61VsOWU3kszXtwrsKsWhghQAokJHMZACw5ouZSX_FT7G8.OhfsnWTqfES3ljZLKtDJ9 S1PwXrLghT9cQNL8TmWa6zGJfKW9LLNL1hR5tT9yTrlHEYA2aKlMPOPDDoWYlIRsnQPC_ftBRoNM 7yo6tmdh3xae.uVi6zocjbu9ozsmZQgdrBqoyPbLp5yA1lOtJlfvTVZlqIGMqYFMFo2IT1H0.Jc8 6bqI9opJmhPLMNBTY_gyRI8jXJSg2cXCaqllNAL5Txv6kYHKRux_AHL1xW_RCKkdL4wcmC8w6ZtI Y98KKR3G4V6FIgOyj5avS4HVfZcI0qbuciWEYE2BzNJ5rbzIFjOREMoCgO5z0GC_nnH6TvPXOeRm 5f3ULTihaIIw3HCFP8SDBq.1O7lyJ38jydihEUc4fOythKt2l.uBqf3Vg_qPVFpZThBn4rfMZbp1 8BWvBd_AW.ZQGNXe0KsStp3nSkQ_nV.WYpHhM3_QjCfK_aek2CK7SMzoI4BvedLvD0eAAtrna5Zt PifhIpJAHKbIvG2LBCB2I9N_pxKH6vKsJGSHUW8z2Tup6ztGlpbE7hTwo2HrM3847yvmMQm8_xCJ qojHKlCefgHyTu4CRT0ZSHty.DS77FtlhWB_3OKAgWiONo4zR.910.iipPiVk05LhJ65XQMenLDu ZpfcKe5nWKo8N38tfuTt3HX7uRWRCH_aAmmOFx_oYi2QxieSXgwcPZG6pnuXTBhnummFaJAR5c8c iQEmsVDhvdSLtPws5wsDYb23U9gljlq1DdM.plFqM5McpOsv_JEayQy0wltn7n79unPu6EPsVkw3 h7gmfpTb8LcnnZifS.mP3mxJyV8lW5p7OoHYDePEsdSR2BMMg1Uza_LgPzkhJYWuHVQfe2YUXp6Z 3 X-Sonic-MF: X-Sonic-ID: f990c685-d2fb-4930-9c73-2fd378848b65 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Dec 2023 20:08:37 +0000 Received: by hermes--production-gq1-6949d6d8f9-hnk4w (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fb5db664a4faa8f6f2d34b13e2bdf9c8; Fri, 22 Dec 2023 20:08:33 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: measuring swap partition speed Date: Fri, 22 Dec 2023 12:08:22 -0800 References: <84A99C91-9DB2-4611-A040-2261C1C46CDE@yahoo.com> To: void , freebsd-fs@freebsd.org In-Reply-To: <84A99C91-9DB2-4611-A040-2261C1C46CDE@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.31:from]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[f-m.fm,freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SxdfH3msyz4L6v X-Spamd-Bar: --- On Dec 22, 2023, at 10:17, Mark Millard wrote: > void wrote on > Date: Fri, 22 Dec 2023 16:59:10 UTC : >=20 >> My assessment of the "system being inactive while testing" may have >> been inaccurate. By "being inactive" I was looking at avg load being >> 1% or less, and for swap use being 0. Maybe the initial "inactive" = test=20 >> should have been in single user mode [1] because the tests in this = mode >> show no (I mean much less) of a speed issue. Apologies for not = considering=20 >> single user mode till now. The results in single user mode seem to me = to=20 >> infer that there is no problem with the hardware. >=20 > Suggestion: Compare/contrast what you see via "gstat -spod" for single > user vs. not when you are not deliberately running the swap I/O > test but other things are similar to when you do. >=20 >> I have been able to reliably create the problem by rebooting the >> computer, then running something that does not need to be one huge = chunk of data, >> that doesn't load the system that much, so ran 'make installworld' = and in another=20 >> terminal ran the write-to-swap-partition test [2]. >=20 > I suggest monitoring what "gstat -spod" shows during a make = installworld > run (no competing writes to swap). Then with both going in overlapping > time frames: what is noticably different? >=20 > I wonder if UFS vs. ZFS contributes for the RAM-related bandwidth = limited > RPi4B. (One core can saturate the RAM-related subsystem depending on > how effective the RAM caching happens to be for the access patterns > involved.) >=20 >> It shows in this context=20 >> that writing to the filesystem effectively blocks writing to swap.=20 >> 507 kB/s compared to 16 MB/s. I don't know if this is unique to arm64 = or=20 >> if it's also the case on other arches, but it seems suboptimal to me. >=20 > I do not have a built world to install on my stable/14 snapshot > media. I'll have to switch to a main [so: 15] media (that is not > up to date) if I'm going to provide some sort of matching type > of activity comparison/contrast. This would be using a newer > USB3 NVMe media. Probably UFS instead of ZFS instead: I may not > have both of the main [so: 15] media available to me for now. >=20 > If I do this, it will likely not be quickly. I have ZFS media available. so I'm using that here. The main [so: 15] context for the ZFS test goes back to 2023-Sep-21 or so for main: # uname -apKU FreeBSD CA72-4c8G-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #118 = main-n265447-e5236d25f2c0-dirty: Thu Sep 21 09:13:36 PDT 2023 = root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1500001 1500001 I normally use -j$(sysctl -n hw.ncpu) for installworld but, if I gather right, you effectively used -j1 (implicit), so I'll do both styles, -j4 being appropriate for RPi4B's. I'll note that I use ssh sessions instead of the serial console (no video connected). The I/O for the serial console would greatly slow the make installworld, waiting for output. Of source I do not know your make installworld context, so I'm just doing what I normally relative to such issues. I've done one serial console example as well, for reference. Booted multi-user but no make installworld in progress (ssh session): # dd if=3D/dev/urandom of=3D/dev/da0p7 bs=3D8k conv=3Dsync = status=3Dprogress ^C562470912 bytes (562 MB, 536 MiB) transferred 26.043s, 22 MB/s 69267+0 records in 69266+0 records out 567427072 bytes transferred in 26.274117 secs (21596428 bytes/sec) Booted multi-user but with make installworld in progress (no -jN) (ssh = session): # dd if=3D/dev/urandom of=3D/dev/da0p7 bs=3D8k conv=3Dsync = status=3Dprogress ^C591372288 bytes (591 MB, 564 MiB) transferred 32.001s, 18 MB/s 73785+0 records in 73784+0 records out 604438528 bytes transferred in 32.872265 secs (18387493 bytes/sec) Booted multi-user but with make -j4 installworld in progress (ssh = session): # dd if=3D/dev/urandom of=3D/dev/da0p7 bs=3D8k conv=3Dsync = status=3Dprogress ^C551559168 bytes (552 MB, 526 MiB) transferred 35.001s, 16 MB/s 69285+0 records in 69284+0 records out 567574528 bytes transferred in 35.917269 secs (15802274 bytes/sec) Booted multi-user but with make -j4 installworld in progress (serial = console): # dd if=3D/dev/urandom of=3D/dev/da0p7 bs=3D8k conv=3Dsync = status=3Dprogress ^C642711552 bytes (643 MB, 613 MiB) transferred 31.000s, 21 MB/s 78521+0 records in 78520+0 records out 643235840 bytes transferred in 31.024779 secs (20732971 bytes/sec) Compared/contrasted to yours, it again suggests seek-time as a potential notable contribution to the results in your context: the spinnig rust spends far more overall time between command, limiting the command processing rate. Plugging in and using a separate USB3 SSD suitable for use as swap might be a help, despite the shared bandwidth for the 2 USB3 ports. Even using the USB2 port could be useful, and might have a more independent bandwidth. =3D=3D=3D Mark Millard marklmi at yahoo.com