[reiserfs-list] big reiserfs regression in 2.4.20-pre2
On a quad xeon with 3.75 gb ram there was a big regression in dbench and tiobench with many threads between 2.4.20-pre1 and 2.4.20-pre2. Below is from 5 dbench runs. There was a 23% regression at 192 processes reiserfs dbench 192 processesAverage HighLow 2.4.20-pre1 55.9458.17 54.26 2.4.20-pre2 42.9844.73 42.30 And 13% regression at 64 processes. dbench 64 processes Average HighLow 2.4.20-pre1 70.98 72.53 69.47 2.4.20-pre2 61.93 64.01 57.31 ext2 and ext3 did not change between 2.4.20-pre1 and pre2. ext3 dbench 192 processesAverage HighLow 2.4.20-pre1 60.50 61.47 59.01 2.4.20-pre2 60.61 61.63 58.80 dbench 64 processes Average HighLow 2.4.20-pre1 82.73 89.63 64.67 2.4.20-pre2 83.12 91.28 65.11 ext2 dbench 192 processesAverage HighLow 2.4.20-pre1 116.32 124.44 110.95 2.4.20-pre2 116.45 119.89 109.89 dbench 64 processes Average HighLow 2.4.20-pre1 145.61 158.67 102.33 2.4.20-pre2 145.77 158.96 103.89 CPU utilization on reiserfs went down in the high thread count tiobench tests, but it also had a throughput regression when there was more than one thread most tests. ext2 and ext3 didn't have a regression. tiobench-0.3.3 Unit information File size = 12288 megabytes Blk Size = 4096 bytes Rate = megabytes per second CPU% = percentage of CPU used during the test Latency = milliseconds Lat% = percent of requests that took longer than X seconds CPU Eff = Rate divided by CPU% - throughput per cpu load Sequential Reads reiserfs had the biggest drop in throughput. NumAvg Maximum Lat% Lat% CPU Kernel Thr Rate (CPU%) Latency Latency >2s >10s Eff - --- -- 2.4.20-pre1 1 35.11 23.02% 0.331 107.07 0.0 0.0 152 2.4.20-pre2 1 34.68 22.83% 0.335 119.57 0.0 0.0 152 2.4.20-pre1 32 27.27 20.12%11.536 258436.68 0.01275 0.01135 136 2.4.20-pre2 328.00 6.05%43.881 7568.44 0.00096 0.0 132 2.4.20-pre1 64 26.50 19.63%21.328 361756.08 0.02183 0.02053 135 2.4.20-pre2 648.42 6.46%79.03915721.84 0.18813 0.0 130 2.4.20-pre1128 27.72 21.17%35.485 814716.92 0.02671 0.02549 131 2.4.20-pre21289.30 7.10% 135.05632520.09 3.92532 0.00035 131 2.4.20-pre1256 26.55 19.95%68.425 825224.03 0.04636 0.04515 133 2.4.20-pre22568.47 6.49% 285.43062013.50 4.68931 0.11676 131 Random Reads reiserfs went down when there is more than 1 thread. NumAvg Maximum Lat% Lat% CPU Kernel Thr Rate (CPU%) Latency Latency >2s >10s Eff - --- -- 2.4.20-pre1 10.68 0.84%17.320 51.54 0.0 0.0 81 2.4.20-pre2 10.70 0.76%16.787 53.99 0.0 0.0 92 2.4.20-pre1 323.09 6.80% 102.783 535.46 0.0 0.0 46 2.4.20-pre2 321.98 3.84% 147.78016015.44 0.55000 0.0 52 2.4.20-pre1 643.10 5.99% 178.64110722.38 0.50403 0.0 52 2.4.20-pre2 642.18 3.70% 229.51116850.53 2.77218 0.0 59 2.4.20-pre11283.35 5.27% 226.876 9018.16 1.91532 0.0 64 2.4.20-pre21282.31 3.98% 378.51117932.69 5.77117 0.0 58 2.4.20-pre12563.26 6.44% 249.264 5751.33 0.57292 0.0 51 2.4.20-pre22562.20 5.53% 724.34019268.40 13.09896 0.0 40 Sequential Writes reiserfs cpu utilization went down, but throughput dropped. NumAvg Maximum Lat% Lat% CPU Kernel Thr Rate (CPU%) Latency Latency >2s >10s Eff - --- -- 2.4.20-pre1 1 39.31 71.71% 0.282 6301.59 0.00012 0.0 55 2.4.20-pre2 1 38.28 73.39% 0.290 8058.03 0.00019 0.0 52 2.4.20-pre1 32 29.64 119.5%11.17116619.06 0.18094 0.0 25 2.4.20-pre2 32 23.52 103.0%10.24217721.55 0.13629 0.0 23 2.4.20-pre1 64 29.02 115.6%22.06538792.62 0.38675 0.00426 25 2.4.20-pre2 64 20.92 84.06%19.44941273.31 0.33824 0.00480 25 2.4.20-pre1
Re: [reiserfs-list] big reiserfs regression in 2.4.20-pre2
>>> Is regression going away if you pass this mount option to reiserfs: >>> -o alloc=preallocmin=4:preallocsize=9 >> Yes. > Great, I just found that we forgot to enable preallocation with new block > allocator by default. This is easily fixable of course. Is that in the 2.5.patch: http://marc.theaimsgroup.com/?l=linux-kernel&m=102984193227185&w=2 Or will it be different for 2.4? -- Randy Hron http://home.earthlink.net/~rwhron/kernel/bigbox.html
Re: [reiserfs-list] big reiserfs regression in 2.4.20-pre2
Hello! On Tue, Aug 20, 2002 at 11:26:32PM -0400, [EMAIL PROTECTED] wrote: > > Great, I just found that we forgot to enable preallocation with new block > > allocator by default. This is easily fixable of course. > Is that in the 2.5.patch: > http://marc.theaimsgroup.com/?l=linux-kernel&m=102984193227185&w=2 Yes, I included it into 2.5 patch, since I see no reason to supply buggy patch and then several bugfixes. Bye, Oleg
