One interesting thing not considered by these benchmarks is how much time
is spent in the driver interrupt handlers.
Under Linux, interrupts are handled in the context of the current
_running_ process, and charged as such. The process on behalf of
which disk I/O is being performed is often in disk wait; so CPU time
used for some of its I/O is charged to some other task or dropped if
all processes are sleeping and the interrupt handler must run in the
context of the idle task.
This will be most significant with the IDE drivers; causing IDE CPU usage
to show favorably.
I don't think we can solve this in the kernel - do_gettimeofday() is
way too expensive to use to clock interrupts, and jiffies isn't fine
enough grained.
However, in a user level benchmark it would be fairly trivial to fork
off another process which does something like bump a long long counter
in a loop, and compare the number of loops per unit CPU time without
the I/O benchmark running versus the number of loops per unit CPU time
with the I/O benchmark running; synchronize the processes with shared
memory.
Any volunteers?