Re: Profiling a build

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Wed, 10 Dec 2025 06:11:02 -0000 (UTC)
mlelstv%serpens.de@localhost (Michael van Elst) wrote:

> Saying that, NFS is not ideal for building, there is lots of latency
> added to even traversing file paths, and with many files (like in
> a pbulk scenario), the filesystem caches won't be effective.

I have two Raspberry Pi 4 SOCs and each has Samsung T7 SSD attached to
USB3 port. For sequential writes using 64 KiB block size I get these
metrics:

NetBSD-10 local UFS file system:
  5717.50 msec, 179.10 MiB/sec, 2865.59 Blocks/sec, 348.97 usec/Block
NetBSD-10 NFSv3 network share:
  10923.26 msec, 93.74 MiB/sec, 1499.92 Blocks/sec, 666.70 usec/Block
----------------------------------------
Debian-12 local XFS file system:
  9138.81 msec, 112.05 MiB/sec, 1792.79 Blocks/sec, 557.79 usec/Block
Debian-12 NFSv3 network share:
  16048.65 msec, 63.81 MiB/sec, 1020.90 Blocks/sec, 979.53 usec/Block

I did not expect NetBSD NFSv3 server to outperform Linux NFSv3 server.
The only tuning I did was to specify 16 NFS server threads on both
machines.

I did have some issues with NFS file locking when running NetBSD
build.sh from a 16-core Linux client, but I worked around those by
mounting NFS shares with nolock,local_lock=all options. After that
building on NFS shares (both source and object files kept there) works
pretty well.