big ext3 sequential write improvement in 2.5.51-mm1 gone in 2.5.53-mm1?
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
lovely. These two files have perfectly intermingled blocks.
Writeback? or read?
Both.
The fileystems need fixing....
Did you add a secret sauce to 2.5.59-mm2? 10x sequential write improvement on ext3 for multiple tiobench threads.
Quad P3 Xeon (4GB ram)
8 GB files
4K blocksize
32 threads
Rate = MB/sec
latency in milliseconds
Sequential Writes ext3
Avg Maximum Lat% Lat% CPU Kernel Rate (CPU%) Latency Latency >2s >10s Eff ---------- ------------------------------------------------------------ 2.4.20aa1 11.85 72.77% 11.814 21802.73 0.05036 0.00000 16 2.5.59 3.42 17.36% 83.976 3109518.52 0.11253 0.05088 20 2.5.59-mm2 32.39 34.28% 7.742 340597.62 0.04287 0.01765 94
Similar improvement for seq writes for 2, 4, 8, 16, 64, 128, 256 threads.
Sequential reads on ext3 with 2.5.59-mm2 improves around 3x for various thread counts. Below is 32 threads.
Sequential Reads ext3
Avg Maximum Lat% Lat% CPU Kernel Rate (CPU%) Latency Latency >2s >10s Eff ---------- ------------------------------------------------------------ 2.4.20aa1 8.24 7.21% 28.587 449134.11 0.10395 0.07086 114 2.5.59 9.50 5.50% 36.703 4310.62 0.00000 0.00000 173 2.5.59-mm2 35.28 17.69% 10.173 18950.56 0.01010 0.00000 199
Signature · 2 lines
Randy Hron http://home.earthlink.net/~rwhron/kernel/bigbox.html
Quoted 2 lines · [email protected] wrote:
Did you add a secret sauce to 2.5.59-mm2?
I have not been paying any attention to the I/O scheduler changes for a couple of months, so I can't say exactly what caused this. Possibly Nick's batch expiry logic which causes the scheduler to alternate between reading and writing with fairly coarse granularity.
Quoted 1 line
10x sequential write improvement on ext3 for multiple tiobench threads.
OK...
I _have_ been paying attention to the IO scheduler for the past few days. -mm5 will have the first draft of the anticipatory IO scheduler. This of course is yielding tremendous improvements in bandwidth when there are competing reads and writes.
I expect it will take another week or two to get the I/O scheduler changes really settled down. Your assistance in thoroughly benching that would be appreciated.
Quoted 3 lines
2.4.20aa1 8.24 7.21% 28.587 449134.11 0.10395 0.07086 114 2.5.59 9.50 5.50% 36.703 4310.62 0.00000 0.00000 173 2.5.59-mm2 35.28 17.69% 10.173 18950.56 0.01010 0.00000 199
boggle.
Quoted 10 lines · Andrew Morton
Quoted 2 lines · [email protected] wrote:
Did you add a secret sauce to 2.5.59-mm2?
I have not been paying any attention to the I/O scheduler changes for a couple of months, so I can't say exactly what caused this. Possibly Nick's batch expiry logic which causes the scheduler to alternate between reading and writing with fairly coarse granularity.
Yes, however tiobench doesn't mix the two. The batch_expire helps probably by giving longer batches between servicing expired requests. The deadline-np-42 patch also eliminates corner cases in which requests could be starved for a long time. A large batch_expire as in mm2 is not a good solution without my anticipatory scheduling stuff though as writes really starve reads.
Quoted 17 lines
Quoted 4 lines
10x sequential write improvement on ext3 for multiple tiobench threads.
OK...
I _have_ been paying attention to the IO scheduler for the past few days. -mm5 will have the first draft of the anticipatory IO scheduler. This of course is yielding tremendous improvements in bandwidth when there are competing reads and writes.
I expect it will take another week or two to get the I/O scheduler changes really settled down. Your assistance in thoroughly benching that would be appreciated.
Quoted 7 lines
Quoted 4 lines
2.4.20aa1 8.24 7.21% 28.587 449134.11 0.10395 0.07086 114 2.5.59 9.50 5.50% 36.703 4310.62 0.00000 0.00000 173 2.5.59-mm2 35.28 17.69% 10.173 18950.56 0.01010 0.00000 199boggle.
I'm happy with that as long as they aren't too dependant on the phase of the moon. The initial deadline scheduler had quite a lot of problems with these workloads.