[BENCHMARK] 100Hz preempt v nopreempt contest results

[BENCHMARK] 100Hz preempt v nopreempt contest results

[Con Kolivas]

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

Re: [BENCHMARK] 100Hz preempt v nopreempt contest results

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

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

Re: [BENCHMARK] 100Hz preempt v nopreempt contest results

[William Lee Irwin III]

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