Messages in this thread | | | Date | Thu, 19 Jun 2003 18:28:35 +1000 | From | Nick Piggin <> | Subject | Re: i/o benchmarks on 2.5.70* kernels |
| |
rwhron@earthlink.net wrote:
>>tiobench on SMP results are not very good, lots of >>fragmentation >> > >On uniprocessor with IDE disk, benchmarks look very >different than SMP/SCSI. Recent -mm on uniprocessor >is frequently ahead of 2.5.70/2.5.71. >
Thanks. AS should be OK with SMP, but it would be nice to see how it goes with a large number of spindles and processors.
AS should also be able to run SCSI alright, it tends to perform quite poorly with TCQ and multiple random readers though unfortunately. I'm setting up a box here with an IDE and SCSI disk which I'll run my regression tests on, (previously only IDE) so I might be able to help this along a bit.
Fairness and interactiveness with AS and big TCQ should be quite a bit better than deadline though, so it would be a good workstation option even if it can't keep database throughput up.
It looks like database loads without TCQ are often better with AS than deadline, your AIM7 is, WimMark is. They can be worse though. pgbench for example.
> >Sequential Reads ext2 > Num Avg Maximum Lat% Lat% CPU >Kernel Thr Rate (CPU%) Latency Latency >2s >10s Eff >----------------- --- ------------------------------------------------------------ >2.4.21-rc8aa1 1 19.00 71.72% 0.597 215.09 0.00000 0.00000 26 >2.5.70-mm6 1 14.26 21.45% 0.812 247.12 0.00000 0.00000 66 >2.5.71 1 14.13 18.03% 0.822 225.37 0.00000 0.00000 78 >2.5.70-mm7 1 14.08 22.96% 0.821 315.76 0.00000 0.00000 61 >2.5.70-mm5 1 14.00 23.80% 0.826 329.88 0.00000 0.00000 59 >2.5.70-mm3 1 13.95 23.75% 0.830 188.64 0.00000 0.00000 59 >2.5.70-mm1 1 13.80 23.84% 0.840 301.10 0.00000 0.00000 58 >2.5.69-ac1 1 13.66 20.44% 0.850 298.83 0.00000 0.00000 67 >2.5.70 1 13.60 20.57% 0.853 174.52 0.00000 0.00000 66 > Don't ask me what the deal is here ;) AS would have no impact on a single threaded IO load. aa is using a lot of CPU for some reason. Driver difference maybe? readahead? Andrea's secret sauce?
aa also gets much worse latency spikes at higher thread counts (if tiobench is to be believed!). As thread count rises readahead can't fit into the request queue, and you see AS working.
On the write side, current mms should be improved due to some changes in request allocation.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |