From nobody Fri Oct 3 04:43:45 2025 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 4cdGJs1Gfqz69T7W for ; Fri, 03 Oct 2025 04:43:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4cdGJr5PhPz3WQZ for ; Fri, 03 Oct 2025 04:43:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="hqX6/pWz"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1759466630; bh=44ibT7gdqPSy3cyxeRbNlLsBYAVSv9m5H0ANBLlt5CU=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=hqX6/pWzSPYdkKhzRxwMf+Khod/cWAtJPouoJ1hd3xOkLiN3FvIv0J3xNgQQOxBGSP00hyyLG5LpdHtq0uKdVBtinC3TQigdtQo10zT33Ta2GD9LkYji7Jtg2lxJ5Q+e+mEQoDTLRD8tAx20w369lcW0xrdOG6GNgHYYyaWpE1QCL2+jqP2Y+IlO2bS+U0bSMsWuudECvQayCkNZoPFK9w7OWmD+VzC3ZAlrNU2AKSFKnjbcE2V5zfw0S7fxsnPMw/PkmTLY7/fwpcVHM0aX+WFDJjOi5elfz+MnddYNN7wBzb2BpV6boZK267VP9kgXb9lPY3SIWktO1AZNawvIVw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1759466630; bh=nSJg3Yej6vNUk1NFWNxm/0Nt3w3BrERUQ/FjD3R7QAm=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=n6+0bGS1+zRQi2UzsE2s3k+RLjGU8OECaQkz3tBVefibBQE/9I84Huj0XOvduFwdExyz7wlmvQYMYY3a2s2GXK9jcpkpGcWi9T1BsYbglUOi3Oqzw8n68/FABWO78O5VTzLKJeGlywEWQAINTujm3INLVDj/eh1KuNmShTIMuHEOPOeq4zCrRPxxcNvinO+e8YPAmwxJm5lynTycjt9eOiK4CxwaHwJUDgk1opkgXF2HQyiBty+D9ui63xQOOORVJGGJ64vEAwXpvjfx4GO1kH0S3DoqgZEAPPkYRG3mTXp3On0PSS3hdyqFEnIZTl/fTmq31ZbGv7fJg6pKSivw4A== X-YMail-OSG: B8X7J0oVM1ky1dHy9wz56i3nWCIlmAgJyw3mhlsf4a1M2kc.6723we3cS2ZuZY_ feOPniBgj4xe2W.gDmRgsMPmQI0gGBmYeXWAwjW0XTTBjz_wvXGnD2zLLMCWyG5BZrdeqgJdS0Ya C6Mevaq7TF16VFGm.x8EXLxxQq4NFinYNDLl1hsdxn4VYQGeBRy9IcfEd0qI7WzkjIFmT25WbeVq Qp6UkF3rci6E2ubee0zuIFh.3PaqpIwShTxa2UT_hTrhHE5WSMZ55pwXKnniZebM_Cje7hUbmdR0 LLO9im4voxJHcBmU0GQ_HNeB7qwdJ0uBb910juAEHA33x96ocigK1Y7_WaYLhosJobn.NawkeeLg dRIIu_0rC_XYo4z1vk6eiOlTQqEESm1BNyVs2ErAhJwCHkvG_VYsbCHgtmH2xypoleyozGoP.NjY 0hWqBcVMEhZXC1eCda2Vchtw8wvR8ggp3tske6PHJ7MTh4CnFrK_y1jtN4Epu6Uxp8Bkm_G8uL8d SrO23oJmZBctwBhqRGsizxHlmh5UbyONN0uXi.65P6.fx99cjh6ke0KuqRXU1XUNqJNS.owZcBUt R3LFqq4ir8IWkbOjVRSQsD5VM3sFUt2u2sh5X8NZpEekkTaiEgP8jRf9VDYhCQCozCKeusg5F6Yr rjDxc4Sn8wfEEkT1vq9lCT6QyYiTN9dmC2mTXYS9gzgOmGH1fsEOJE7BB8jofcmVD1cOFzYxF817 PlguQrW13O1HK87vN6dz0SwRfO2r5fjH4q5NAssEmxf_o83STJqR5oFbU0ANnXIqF8t6o9FbCHkq c4m.M_oHsrmu_fIKcPYtM8LtoViWd7l.gxLqZdIfX.3MgynhfTkW3B06LMzVutQq_rMMY6qtUZw. hPZagmA5TwQ6hhcmbx1xSjzkoBpqbheI6XavJmekpGuUmkzDLuldICDnQLSa3NAsjzIXhi2CybGr ouCVFuI_JCJN4_XgEyjwWIuQM6Y643pB38HBBslxBS.gytjywPaX0YBhn75szZGqlA6f358y_QqA qmeaK4WumDwzMnANLS4KIqyK0rC35zuvgvOiLIIm7eCnIi1FUwyWn9EtSiEO2CNxnmCEgS2tbxYW pwLpZOgZilCwLRMhwdxpvyDx3SvnpUCjG0GuNe3sPweit8tPHi7jYJt5WaGlXyPqc9u49.cmjSX_ EZl9.QYUk2o8HEoM5JryMP8hkiHQT68xQ0z1Km2npV1M6A.kWclOm45U7bNUeJETPJ4OSnpKMOIx 38vTsnPCf30g6J7qOKz0ctKXbB_ttWxbHTAl_pMF.OIT48wCt8Xz7xdwScO6RQjxEx2w.iqgcNEG vOTAfjPm5vfOAUprAEJCCF3ttXZ0yURXGXDh5thGk8NPiehvmVzo5SnlVfFhK1yi5mx6cUzahqB3 8boQMHvtu4ZNy33PJ6_Wk49XIjSl_gGWWZhg0Y2a8XfAPoOGuFSz5zQPhXk2_yXXA4LCnWGYxKCB FL7WjTEZFlTvQCjfugB7Kt6DPOhhRnq.gWjAFUnYfXUQGq_pdxqZv1uTeXU1gHtzkBpCDvBjaSMM Vf0jrqwEGTrT38jjxP5TRNooB9i.PWUTWjvj4fGKDr1sDbKsRzqRaQKMHfbbrGY2mH_Eux05wrFa 71d5T5JYQsGW8uxsPYKU60LiDRZkwjwadCLb_q8E8juKAXssdnyRCVsofdvvm8x.1zemeAp6Ugc_ AEjSqoph.B7rq7Yi0cCSH0a8NLrTHLrG.OSOowkj1ORRq1.OE5P665xvD8jsSsHyZ3bxQRSy1TcH rJ2iysyGFE8huPMJCx2DiEX5COCK58Dvcx1Ek9njxLk0j4MMtNvJxxx4rW.PgvQ8D0g9qB.6GPc3 gELQ7VtfvyL0tAQ7PBw7nwZIaklWXiFVk9vebbiu02boX_yvgJqxw.28WcKqmlam7D.WAiYC_9W8 m5KtlmtCutWMvRARfgE156060nEwhTALwqJYAH4jZ44t43QdH6b8uiqfMwYjyjIprzMd8xtCxaiG xMHg7H4tC7R4X_aGNLnbsDujjeZvnVbXxA_0pomWAvP3VGFb5xAMK.Qo9bYWacXzZhsSGYMIwFN5 V991bUDr9wuRSKVGwuH0bKfFISzZok5xsnAvcomHTbIKO_Sx1113lb1G5vY1QjvrR0O4FG21vxOl t7fTuFMnuNToqtPzqNbxzfvwg3QiuRX9Sc1MMTYOnPS_fkZMiattyGE.j8j05za.80TQkzwnnG7P XnTklwTMaslakff1GxvpuCobQQT5H X-Sonic-MF: X-Sonic-ID: a9bcfd62-9eed-436f-bf6f-2578524be7fe Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 3 Oct 2025 04:43:50 +0000 Received: by hermes--production-gq1-66b66ffd5-cqpc4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cea828e41377dfa2eed20dfadb154b2e; Fri, 03 Oct 2025 04:43:48 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 \(3826.700.81\)) Subject: Re: main 16 and 15.0-ALPHA4 [on amd64]: using a USB3 context gets extensive "flswai" [and "rename"] STATE time during poudriere builds (UFS context happens to be in use); more Date: Thu, 2 Oct 2025 21:43:45 -0700 References: <46E0F6E8-A365-4C01-BFF8-CE2423B6DA00@yahoo.com> <4D74D446-2078-4A5F-B245-913273E2DDD1@yahoo.com> <03B6ABBE-DF0B-441F-9ABD-5565ADBF29ED@yahoo.com> <93873756-54C8-4408-9395-5E67F0300D5E@yahoo.com> To: FreeBSD Current , FreeBSD-STABLE Mailing List In-Reply-To: <93873756-54C8-4408-9395-5E67F0300D5E@yahoo.com> Message-Id: <9204210A-E61D-4C5D-823B-878848698847@yahoo.com> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.86 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.856]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from] X-Rspamd-Queue-Id: 4cdGJr5PhPz3WQZ On Oct 2, 2025, at 20:45, Mark Millard wrote: > On Sep 30, 2025, at 20:43, Mark Millard wrote: >=20 >> [The new material here ends up being about nameicap_cleanup >> and its exclusive use of mnt_renamelock being one potential >> bottleneck involved here. I make no claim it has anything to >> do with the flswai activity reported. The possible >> bottleneck is an observation, not something that I claim >> there is any alternative to. I do not know if this is of any >> interest or not.] >>=20 >> On Sep 29, 2025, at 16:06, Mark Millard wrote: >>=20 >>> On Sep 29, 2025, at 13:01, Mark Millard wrote: >>>=20 >>>> An example is during the cpdup activities when multiple happen >>>> in overlappingtime frames: >>>=20 >>> I'll note that I see this on the amd64 32-FreeBSD-cpu system >>> but not on the aarch64 8-FreeBSD-cpu Windows Dev Kit 2023 >>> system. May be at some point I'll try the older 16-FreeBSD-cpu >>> aarch64 (Cortex-A72) system. >>>=20 >>> Also, on the 7950X3D amd74 system, I see the behavior with >>> 14.3-Stable. Apparently, this is not new with 15+. It has >>> been a long time since I'd tried using an amd64 system for >>> such activity based on using USB3 media. But it has been >>> common for me for aarch64 over that time frame. >>>=20 >>>> . . . >>>> . . . >>=20 >> . . . >>=20 >>=20 >>>> . . . >>>> . . . >>>>=20 >>>> But I'll also see such on c compiles, ld commands, etc. I've >>>> not seen rename for pkg-static but I have seen flswai for it. >>>>=20 >>>> The system spends lots of time 95%+ idle from the wait >>>> activities. >>>>=20 >>>> I see such directly booted from the USB3 media (a 15.0-ALPHA4 >>>> context on UFS media) and when using that media via chroot >>>> from both ZFS and UFS boots that are not USB based. The ZFS >>>> and UFS boots do not show the behavior with the normal >>>> non-USB3 media used instead. >>>>=20 >>>> The system in use is an AMD 7950X3D with 32 FreeBSD cpus, >>>> 192 GiBytes of RAM. main 16 booting for non-USB boots >>>> and 15.0-ALPHA4 boots for the USB3 boots. kernel and >>>> world are via official pkgbase distribution installs: >>>> it is not a personal build of the kernel or world. >>>>=20 >>>>=20 >>>> . . . >>>> . . . >=20 > I got a test context were I could compare the same > media used on the same USB4 port on a laptop > (Dell Precision 5490, 22 FreeBSD cpus, 32 GiBytes > RAM, 4 USB4 ports), where, on boot, the media ends > up being handled as either: >=20 > ) "nda0 at nvme0" (via involving a Thunderbolt 3 hub) > ) "da0" (via a direct connection) >=20 > (The UEFI/ACPI does enough to make basic operation > work, presenting some view to FreeBSD for media on > USB4 ports.) >=20 > Both have the bottlenecks visible when monitored with > top, both "flswai" and "rename" examples occur in > both contexts. >=20 > But "nda0 at nvme0" bottleneck periods do not last > nearly as long as "da0" bottleneck periods do, making > "nda0 at nvme0" use much more reasonable for the > type of activity. >=20 > Still, this eliminates the possibility that the issue > was limited to USB. It also eliminates it being > specific to the prior AMD (7950X3D) test context. >=20 >=20 > For reference: >=20 > # uname -apKU > FreeBSD USB4sys 16.0-CURRENT FreeBSD 16.0-CURRENT = main-n280801-213170eb956f GENERIC-NODEBUG amd64 amd64 1600001 1600001 >=20 > (It is from official pkgbase distribution use, a > copy of another boot media with some parameters > replaced afterwards.) >=20 > QUOTE > CPU: Intel(R) Core(TM) Ultra 7 165H (3072.00-MHz K8-class CPU) > Origin=3D"GenuineIntel" Id=3D0xa06a4 Family=3D0x6 Model=3D0xaa = Stepping=3D4 > . . . > WARNING: L3 data cache covers more APIC IDs than a package (6 > 3) > FreeBSD/SMP: Multiprocessor System Detected: 22 CPUs > FreeBSD/SMP: Non-uniform topology > END QUOTE >=20 > (The internal NVMe media has Dell's ubuntu on it.) >=20 >=20 > Note: > Ignoring very old Intel MacBook Pro's and Mac Mini > 2018's, none of which I've ever native-booted FreeBSD > on, the Dell P. 5490 is the only Thunderbolt or USB4 > based system that I've access to. I've discovered what is tied to the flswai/rename: Soft Updates had been enabled. Disabling Soft Updates leads to biowr and getblk as what shows for the bottleneck. (There is still a bottleneck.) =3D=3D=3D Mark Millard marklmi at yahoo.com