Re: FreeBSD 8.0 Performance (at Phoronix)

on 01/12/2009 15:25 Robert Watson said the following:
> The threaded I/O is interesting and possiby the greatest concern.  We
> should try to reproduce these in "lab conditions" and attempt to
> understand the workloads more.  We do have known "strong"
> synchronization in the vnode write path, such that writes to the same
> vnode may be serialized in a strong way -- it could be that these tests
> show that up.

BTW, threaded I/O tests are done with tiobench:
http://sourceforge.net/projects/tiobench/

The tool compiles fine on FreeBSD.
I believe the tests were executed with options like the following:
tiotest -k3 -k2 -k1 -f 64 -t 4

As I understand the test number zero (sequential write) has always to be executed,
because it produces the files needed for other tests.

It seems that all phoronix tests were done using 4KB reads/writes.  No syncing
and/or direct io was done.
So, for example, the first test essentially did the following:
- create 4 files
- create 4 threads
- each thread sequentially writes 4KB chunks to its own file
- measured value is delta between gettimeofday before and after each 4KB write(2)
  call

For random write test the same files are reused.  The threads do (pseudo-)random
seeks within the files before doing the writes.

There is fsync() call at the end of each write test, its time is not accounted.
For read tests the same files are re-used again.

So we should understand that this test depends on many things before disk writing
gets involved.  E.g. VM/bufache strategy, fs tuning.

For instance, compare sequential write test with 32 threads and random write test
with the same number of threads.  The article boasts:
"Ubuntu and Fedora did shockingly better, but for those unfamiliar with the
Phoronix Test Suite, tests are generally ran multiple times [...] for accuracy."
But notice that Ubuntu and Fedora results for random write test are *better* than
for the sequential test with all other setting being equal.
I think that that speaks of something about the test method.
The numbers are so ridiculously small that it looks like the writes never reached
disks, at least before fsync().


There are other systemic questions.
E.g. why sequential write test was performed with both 4 thread and 32 thread
configurations, but other tests only with 32 threads.  In general, we don't see
how changing parameters affect results for the OSes, e.g. chunk size, total write
size, etc.

-- 
Andriy Gapon