If I do:

dsl@snowdrop:-ksh$ cd /usr/bsd-current
dsl@snowdrop:-ksh$ time find . | wc
  109552  109552 4153470
  166.93s real     1.81s user     1.23s system
dsl@snowdrop:-ksh$ time find . |wc
  109552  109552 4153470
  165.35s real     1.75s user     1.27s system

Repeating the find takes about the same length of time, the disk
'rattles' throughout.  Memory use (reported by 'top') stays basically
constant 'Memory: 33M Act, 308K Wired, 187M Free, 1025M Swp free'.

It is as if some of the disk accesses are not going through the UVM - so
fail to make use of the free memory in the system.

If you process a slightly smaller directory structure, the data is
cached somewhere.

dsl@snowdrop:-ksh$ cd src/sys
/usr/bsd-current/src/sys
dsl@snowdrop:-ksh$ time find . |wc
   18549   18549  555285
   28.33s real     0.21s user     0.23s system
dsl@snowdrop:-ksh$ time find . |wc
   18549   18549  555285
    0.33s real     0.25s user     0.08s system

I can't see any reason for restricting the amount of physical memory
used for file system control structures.

I have a 'gut' feel that similar accesses happen during a system build -
there seem to be far too many disk accesses when compiling lots of files
in the same directory - you would expect all the required disk blocks
(except the .c file) to be resident.  (I have a memfs /tmp).

	David