psort - concurrent file system test
/testbin/psort [-p numprocs] [-k numkeys] [-r | -s randomseed]
psort does an on-disk parallelizing sort of a large number of randomly generated integers. It is loosely based on some real parallel sort benchmarks.
Be aware of its size vs. the size of your buffer cache, and adjust its size as needed. Running it so it fits entirely in cache and running it so it overflows the cache are both valid stress tests, but have quite different characteristics.
The memory footprint depends on the number of processes and the per-process work buffer size (which can be changed at compile time); the file system footprint depends on the number of integers. Specifically, the memory footprint is the number of processes (default 4) times the buffer size (default 384K), and the file size is the number of integers (default 131,072) multiplied by the size of an integer (here 4) multiplied by the maximum number of copies of the data that appear at once, which is 3, so 1.5 MB.
Note that the parent psort process does not serve as one of the worker processes; it also has a work buffer, but doesn't use it. Also note that it forks several (six) sets of subprocesses in the course of execution. A virtual memory system that doesn't support the zerofilled page optimization will both use 1/n more memory for the extra work buffer and also incur a fairly large cost copying it in every fork. Also, because of the large number of forks the amount of RAM required to run psort using dumbvm is likely prohibitive.
psort uses the following system calls:
It also execs cat.psort should be able to run properly on SFS filesystems once the basic system calls are implemented. However, you may need to adjust its workload size depending on the level of large-file support you have in SFS.
psort will mostly run on emufs, but there isn't really much point in that.