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

On Oct 2, 2025, at 20:45, Mark Millard <marklmi@yahoo.com> wrote:

> On Sep 30, 2025, at 20:43, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> [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.]
>> 
>> On Sep 29, 2025, at 16:06, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>>> On Sep 29, 2025, at 13:01, Mark Millard <marklmi@yahoo.com> wrote:
>>> 
>>>> An example is during the cpdup activities when multiple happen
>>>> in overlappingtime frames:
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>>> . . .
>>>> . . .
>> 
>> . . .
>> 
>> 
>>>> . . .
>>>> . . .
>>>> 
>>>> 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.
>>>> 
>>>> The system spends lots of time 95%+ idle from the wait
>>>> activities.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> . . .
>>>> . . .
> 
> 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:
> 
> ) "nda0 at nvme0" (via involving a Thunderbolt 3 hub)
> ) "da0"           (via a direct connection)
> 
> (The UEFI/ACPI does enough to make basic operation
> work, presenting some view to FreeBSD for media on
> USB4 ports.)
> 
> Both have the bottlenecks visible when monitored with
> top, both "flswai" and "rename" examples occur in
> both contexts.
> 
> 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.
> 
> 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.
> 
> 
> For reference:
> 
> # uname -apKU
> FreeBSD USB4sys 16.0-CURRENT FreeBSD 16.0-CURRENT main-n280801-213170eb956f GENERIC-NODEBUG amd64 amd64 1600001 1600001
> 
> (It is from official pkgbase distribution use, a
> copy of another boot media with some parameters
> replaced afterwards.)
> 
> QUOTE
> CPU: Intel(R) Core(TM) Ultra 7 165H (3072.00-MHz K8-class CPU)
> Origin="GenuineIntel"  Id=0xa06a4  Family=0x6  Model=0xaa  Stepping=4
> . . .
> 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
> 
> (The internal NVMe media has Dell's ubuntu on it.)
> 
> 
> 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.)

===
Mark Millard
marklmi at yahoo.com