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 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.


===
Mark Millard
marklmi at yahoo.com