* [BENCHMARK] 100Hz preempt v nopreempt contest results
@ 2003-06-03 6:39 Con Kolivas
2003-06-03 17:05 ` Robert Love
0 siblings, 1 reply; 3+ messages in thread
From: Con Kolivas @ 2003-06-03 6:39 UTC (permalink / raw)
To: linux kernel mailing list; +Cc: Zwane Mwaikambo, Robert Love
-----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-----
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BENCHMARK] 100Hz preempt v nopreempt contest results
2003-06-03 6:39 [BENCHMARK] 100Hz preempt v nopreempt contest results Con Kolivas
@ 2003-06-03 17:05 ` Robert Love
2003-06-03 17:24 ` William Lee Irwin III
0 siblings, 1 reply; 3+ messages in thread
From: Robert Love @ 2003-06-03 17:05 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux kernel mailing list, Zwane Mwaikambo
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BENCHMARK] 100Hz preempt v nopreempt contest results
2003-06-03 17:05 ` Robert Love
@ 2003-06-03 17:24 ` William Lee Irwin III
0 siblings, 0 replies; 3+ messages in thread
From: William Lee Irwin III @ 2003-06-03 17:24 UTC (permalink / raw)
To: Robert Love; +Cc: Con Kolivas, linux kernel mailing list, Zwane Mwaikambo
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-06-03 17:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-03 6:39 [BENCHMARK] 100Hz preempt v nopreempt contest results Con Kolivas
2003-06-03 17:05 ` Robert Love
2003-06-03 17:24 ` William Lee Irwin III
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).