To assess the performance impact of the LL patch I used the
ISO-standard benchmark of compiling the Linux kernel.
Executive summary: Nil impact.
Methodology:
1: <reboot>
2: Run this:
#!/bin/zsh
0 /etc/rc.d/init.d/crond stop
IN=$(cat /proc/stat)
echo $IN
time (make -j3 clean && make -j3 bzImage && make -j3 modules)
echo $IN
cat /proc/stat
500MHz Celeron, UP kernel, with low-latency patch (5 runs):
Total context switches Time
104445 358.80s user 26.83s system 95% cpu 6:45.31 total
104112 358.95s user 26.37s system 95% cpu 6:44.88 total
104179 360.07s user 27.06s system 95% cpu 6:45.57 total
104161 357.33s user 27.88s system 95% cpu 6:45.41 total
104170 356.57s user 27.87s system 95% cpu 6:42.67 total
500MHz Celeron, UP kernel, without low-latency patch (3 runs):
104050 358.93s user 27.41s system 95% cpu 6:46.27 total
104162 359.81s user 27.09s system 95% cpu 6:44.71 total
104101 357.73s user 26.98s system 94% cpu 6:45.83 total
Dual 500MHz Celeron, with low-latency patch (4 runs):
108227 419.87s user 37.80s system 169% cpu 4:30.69 total
109202 422.18s user 39.00s system 169% cpu 4:31.75 total
126651 422.70s user 39.17s system 166% cpu 4:36.85 total
109632 422.91s user 37.99s system 169% cpu 4:31.30 total
Dual 500MHz Celeron, without low-latency patch (2 runs):
109340 421.87s user 38.85s system 169% cpu 4:32.59 total
109226 421.69s user 39.24s system 169% cpu 4:31.17 total
So this is pretty dull from an LL-patch point of view.
>From a wider aspect there are some interesting anomalies.
- Why is the aggregate user time higher when using SMP?
- Ditto the aggregate system time?
- Why only 169% load on SMP?
That may all be due to accounting granularities. But
- Why only 1.5 times speedup on SMP?
This is with a 20 MByte/sec UDMA66 drive, 256 megs.
