scheduler tunables with contest - exit_weight
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
osdl hardware, contest results, 2.5.52-mm2 with scheduler tunable - exit weight (ew1= exit weight ==1 and so on)
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio ew0 [5] 105.3 90 16 22 2.91 ew1 [5] 86.4 97 12 18 2.39 ew2 [5] 74.9 109 9 18 2.07 ew3 [5] 84.2 100 11 19 2.33 ew4 [5] 83.8 102 10 18 2.31 ew5 [5] 89.9 93 12 20 2.48 ew6 [5] 97.5 88 13 20 2.69 ew7 [5] 89.2 95 12 20 2.46
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio ew0 [5] 89.2 90 32 2 2.46 ew1 [5] 90.5 88 33 2 2.50 ew2 [5] 87.2 91 32 2 2.41 ew3 [5] 88.7 92 32 2 2.45 ew4 [5] 91.5 88 32 2 2.53 ew5 [5] 87.7 89 32 2 2.42 ew6 [5] 90.2 87 32 2 2.49 ew7 [5] 88.6 91 32 2 2.45
It seems with these results at least, benefit is gained from it being on versus off. The actual value seems not important wrt contest.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+BNqcF6dfvkL3i1gRAqeeAJ9b3OLhmb0737HfbJG1N9QMOou8gQCeJ6OJ p2IhcdJ3QeBx9k3QX5+6yzk=
=Iaf8
-----END PGP SIGNATURE-----
On Saturday 21 December 2002 22:18, Con Kolivas wrote:
Hey Con,
Quoted 2 lines
osdl hardware, contest results, 2.5.52-mm2 with scheduler tunable - exit weight (ew1= exit weight ==1 and so on)
Can you please try another thing?
kernel/sched.c
/*
* If the child was a (relative-) CPU hog then decrease
* the sleep_avg of the parent as well.
*/
if (p->sleep_avg < p->parent->sleep_avg)
p->parent->sleep_avg = (p->parent->sleep_avg * exit_weight +
p->sleep_avg) / (exit_weight + 1);Remove these please and run again.
ciao, Marc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 17 lines · Marc-Christian Petersen
On Saturday 21 December 2002 22:18, Con Kolivas wrote:
Hey Con,
Quoted 2 lines
osdl hardware, contest results, 2.5.52-mm2 with scheduler tunable - exit weight (ew1= exit weight ==1 and so on)
Can you please try another thing?
kernel/sched.c/* * If the child was a (relative-) CPU hog then decrease * the sleep_avg of the parent as well. */ if (p->sleep_avg < p->parent->sleep_avg) p->parent->sleep_avg = (p->parent->sleep_avg * exit_weight
Quoted 3 lines
+
p->sleep_avg) / (exit_weight+ 1);Remove these please and run again.
Sure why not
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 39.2 181 0 0 1.08 2552mm2noew [5] 39.6 180 0 0 1.09
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 36.5 194 0 0 1.01 2552mm2noew [5] 36.5 194 0 0 1.01
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 46.5 152 8 41 1.28 2552mm2noew [5] 49.1 143 10 50 1.36
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 52.8 154 1 10 1.46 2552mm2noew [5] 57.7 160 1 10 1.59
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 76.1 124 1 8 2.10 2552mm2noew [5] 70.1 128 1 8 1.94
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 74.5 112 11 20 2.06 2552mm2noew [5] 67.3 117 8 17 1.86
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 59.9 134 6 18 1.65 2552mm2noew [5] 66.2 131 9 21 1.83
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 50.5 147 5 6 1.39 2552mm2noew [5] 50.2 149 5 6 1.39
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 43.7 167 0 9 1.21 2552mm2noew [5] 43.5 166 0 9 1.20
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio 2.5.52-mm2 [7] 66.0 141 39 3 1.82 2552mm2noew [5] 64.7 136 38 3 1.79
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+B7yAF6dfvkL3i1gRAhjaAJ4r0rEcvy95o28bw7WoSBoe7ZfmAgCgpHJS HFJaBj8sBtA1MyzK/7qptQg=
=N3fU
-----END PGP SIGNATURE-----
Quoted 7 lines · Con Kolivas
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1osdl hardware, contest results, 2.5.52-mm2 with scheduler tunable - exit weight (ew1= exit weight ==1 and so on)
io_load:
Quoted 9 lines
Kernel [runs] Time CPU% Loads LCPU% Ratio ew0 [5] 105.3 90 16 22 2.91 ew1 [5] 86.4 97 12 18 2.39 ew2 [5] 74.9 109 9 18 2.07 ew3 [5] 84.2 100 11 19 2.33 ew4 [5] 83.8 102 10 18 2.31 ew5 [5] 89.9 93 12 20 2.48 ew6 [5] 97.5 88 13 20 2.69 ew7 [5] 89.2 95 12 20 2.46
In spite of worrying reports of decreasing single task performance, does it make sense to add "null_load" test? ;)
--
vda
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 18 lines · Denis Vlasenko
Quoted 7 lines · Con Kolivas
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1osdl hardware, contest results, 2.5.52-mm2 with scheduler tunable - exit weight (ew1= exit weight ==1 and so on)
io_load:Quoted 9 lines
Kernel [runs] Time CPU% Loads LCPU% Ratio ew0 [5] 105.3 90 16 22 2.91 ew1 [5] 86.4 97 12 18 2.39 ew2 [5] 74.9 109 9 18 2.07 ew3 [5] 84.2 100 11 19 2.33 ew4 [5] 83.8 102 10 18 2.31 ew5 [5] 89.9 93 12 20 2.48 ew6 [5] 97.5 88 13 20 2.69 ew7 [5] 89.2 95 12 20 2.46
Quoted 2 lines
In spite of worrying reports of decreasing single task performance, does it make sense to add "
null_load" test? ;)
I've simplified the data. There is no significant difference in the no_load groups with changes to the scheduler tunables over useful ranges.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+CXyRF6dfvkL3i1gRAtSyAJ9XThpp5iCI1FcjDxVOESbm5ialywCgg7Vb HN+jWurjIwXngqCUOmDWhh0=
=7Iy8
-----END PGP SIGNATURE-----