Skip to contentSkip to conversation

100Hz preempt v nopreempt contest results

BENCHMARK Con Kolivas 3 participants 3 messages Jun 3, 2003

lore
Share & tools
lore
#0 lore raw

-----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-----

#1 lore raw
Quoted 5 lines · Con Kolivas

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

#2 lore raw
Quoted 5 lines · Con Kolivas
Quoted 5 lines

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.

Quoted 5 lines · Robert Love

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