Hello *,

I noticed on a NetBSD3.0 system that building packages with pkg_comp
was slower than building the packages directly and have tried to 
identify the reason.

Background: /usr/pkgsrc is NFS-mounted from a NetBSD1.6.2 server,
the network connection is a 802.11g WLAN and uses an IPSEC tunnel.
The build directory itself (/usr/pkgwrk) is locally, so only
the pkgsrc tree itself and the distfiles are accessed via NFS.

Doing a build in pkg_comp starts about 250-300 NFS operations
per second. nfsstat on the client shows that almost all operations
are 'lookup'.

Doing a build directly in /usr/pkgsrc starts also about 250-300 NFS
operations per second, nfsstat on the client shows almost all operations
to be 'getattr'.

To isolate the problem I have timed a simple 'find /usr/pkgsrc/fonts'
in both environments. That directory consists of 302 directories
and 1016 files.

In the pkg_comp chroot:
1st run       15.28 real 0.01 user 0.28 sys
              603*getattr, 2768*lookup, 605*access
2nd run       10.49 real 0.00 user 0.20 sys
              603*getattr, 2136*lookup, 0*access

Directly in /usr/pkgsrc:
1st run        6.74 real 0.00 user 0.14 sys
              1244*getattr, 2*lookup, 606*access
2nd run        3.23 real 0.04 user 0.04 sys
               914*getattr, 0*lookup, 0*access


Obviously the speed difference comes from the number of NFS operations
which is 3 times as high in the 2nd run when lots of data is already
cached and still 2 times as high in the 1st run.

The pkg_comp environment is a chroot that uses a null mount to access
/usr/pkgsrc from outside the chroot. Mounting the NFS server directly
into the chroot shows the same performance as using the NFS mount
outside the chroot. The impact must come from the null mount.

Now, what creates the extra operations when using the null mount
and why does it cause different operations?

N.B. the speed difference is larger when building packages because
pkgsrc uses lots of very long paths for retrieving buildlink and other
mk files and the number of lookup operation depends on the path lengths.

Greetings,
-- 
                                Michael van Elst
Internet: mlelstv@serpens.de
                                "A potential Snark may lurk in every tree."
-- 
-- 
                                Michael van Elst
Internet: mlelstv@serpens.de
                                "A potential Snark may lurk in every tree."