This one may be considered as a testcase for I/O system optimization.
It is taken from the binutils testsuite,
ld/ld-elf/sec64k.exp
, where this
test may occasionally trigger a timeout. It is
extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24.
$ wget -O - http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz | xz -d | tar -x
$ cd test/
$ \time ./ld-new.stripped -o dump dump?.o dump??.o
0.00user 0.00system 2:46.11elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
On the idle grubber, this one repeatedly takes a few minutes wall time to complete successfully, contrary to a few seconds on a GNU/Linux system.
While processing the object files, there is heavy interaction with the relevant
ext2fs process. Running rpctrace on
the testee shows that (primarily) an ever-repeating series of io_seek
and
io_read
is being processed. Running the testee on GNU/Linux with strace
shows the equivalent thing (_llseek
, read
) -- but Linux' I/O system isn't
as slow as the Hurd's.
As Samuel figured out later, this slowness may in fact be due to a Xen-specific issue, see Xen lseek. After the latter has been addressed, we can re-evaluate this issue here.