Re: iozone write 50% regression in kernel 2.6.24-rc1

[Peter Zijlstra]

Single socket, dual core opteron, 2GB memory
Single SATA disk, ext3

x86_64 kernel and userland

(dirty_background_ratio, dirty_ratio) tunables

---- (5,10) - default

2.6.23.1-42.fc8 #1 SMP

          524288       4   59580   60356
          524288       4   59247   61101
          524288       4   61030   62831

2.6.24-rc2 #28 SMP PREEMPT

          524288       4   49277   56582
          524288       4   50728   61056
          524288       4   52027   59758
          524288       4   51520   62426


---- (20,40) - similar to your 8GB

2.6.23.1-42.fc8 #1 SMP

          524288       4  225977  447461
          524288       4  232595  496848
          524288       4  220608  478076
          524288       4  203080  445230

2.6.24-rc2 #28 SMP PREEMPT

          524288       4   54043   83585
          524288       4   69949  516253
          524288       4   72343  491416
          524288       4   71775  492653

---- (60,80) - overkill

2.6.23.1-42.fc8 #1 SMP

          524288       4  208450  491892
          524288       4  216262  481135
          524288       4  221892  543608
          524288       4  202209  574725
          524288       4  231730  452482

2.6.24-rc2 #28 SMP PREEMPT

          524288       4   49091   86471
          524288       4   65071  217566
          524288       4   72238  492172
          524288       4   71818  492433
          524288       4   71327  493954


While I see that the write speed as reported under .24 ~70MB/s is much
lower than the one reported under .23 ~200MB/s, I find it very hard to
believe my poor single SATA disk could actually do the 200MB/s for
longer than its cache 8/16 MB (not sure).

vmstat shows that actual IO is done, even though the whole 512MB could
fit in cache, hence my suspicion that the ~70MB/s is the most realistic
of the two.

I'll have to look into what iozone actually does though and why this
patch makes the output different.

FWIW - because its a single backing dev it does get to 100% of the dirty
limit after a few runs, so not sure what makes the difference.

Attachment: signature.asc
Description: This is a digitally signed message part