-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here are contest results on the same kernel 2.5.70-mm3 set to 100Hz with
(2.5.70-mm31) and without (2.5.70-mm3n) preempt.
no_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 1 77 94.8 0.0 0.0 1.00
2.5.70-mm3n 1 79 94.9 0.0 0.0 1.00
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 1 74 98.6 0.0 0.0 0.96
2.5.70-mm3n 1 76 98.7 0.0 0.0 0.96
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 2 107 69.2 67.0 29.0 1.39
2.5.70-mm3n 2 137 53.3 133.5 45.3 1.73
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 3 105 73.3 0.7 3.8 1.36
2.5.70-mm3n 3 105 73.3 0.7 3.8 1.33
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 3 122 61.5 2.0 4.9 1.58
2.5.70-mm3n 3 113 65.5 2.0 4.4 1.43
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 4 114 65.8 41.0 19.3 1.48
2.5.70-mm3n 4 112 67.0 41.1 18.8 1.42
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 2 112 67.9 46.1 21.4 1.45
2.5.70-mm3n 2 112 67.0 46.0 20.4 1.42
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 2 100 76.0 7.5 7.0 1.30
2.5.70-mm3n 2 101 75.2 7.6 5.9 1.28
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 2 92 82.6 0.0 5.4 1.19
2.5.70-mm3n 2 94 79.8 0.0 6.4 1.19
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 2 95 81.1 53.0 2.1 1.23
2.5.70-mm3n 2 94 80.9 52.0 2.1 1.19
dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.70-mm31 4 297 24.9 4.5 52.5 3.86
2.5.70-mm3n 4 292 25.7 4.5 52.4 3.70
Note this time the ratio is less useful since they are both 100Hz. The
difference this time shows a large preempt improvement in process_load much
like 1000Hz did. Interestingly, even unloaded kernels no_load and cache_load
runs are faster with preempt. Only in xtar_load (repeatedly extracting a tar
with multiple small files) was no preempt faster.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+3EKfF6dfvkL3i1gRAjFpAKCpeVUOpCXd1xHrKYhEkeOYhuD1swCgmyRQ
NBf56mnwS02WY9wJ9FHctg0=
=cLte
-----END PGP SIGNATURE-----
On Mon, 2003-06-02 at 23:39, Con Kolivas wrote:
> Note this time the ratio is less useful since they are both 100Hz. The
> difference this time shows a large preempt improvement in process_load much
> like 1000Hz did. Interestingly, even unloaded kernels no_load and cache_load
> runs are faster with preempt. Only in xtar_load (repeatedly extracting a tar
> with multiple small files) was no preempt faster.
Thanks for running these, Con.
I think this is an example of kernel preemption doing exactly what we
want it to (improve interactive performance)... probably primarily
because of the more accurate timeslice distribution.
Would be interested to figure out why xtar_load is slower.
Robert Love
On Mon, 2003-06-02 at 23:39, Con Kolivas wrote:
>> Note this time the ratio is less useful since they are both 100Hz. The
>> difference this time shows a large preempt improvement in process_load much
>> like 1000Hz did. Interestingly, even unloaded kernels no_load and cache_load
>> runs are faster with preempt. Only in xtar_load (repeatedly extracting a tar
>> with multiple small files) was no preempt faster.
On Tue, Jun 03, 2003 at 10:05:58AM -0700, Robert Love wrote:
> Thanks for running these, Con.
> I think this is an example of kernel preemption doing exactly what we
> want it to (improve interactive performance)... probably primarily
> because of the more accurate timeslice distribution.
> Would be interested to figure out why xtar_load is slower.
It would be helpful to get more accurate time accounting a la Mike
Galbraith's patches.
-- wli