[RFC][PATCH] scheduler changes
Dimitris Michailidis
dimitris en cthulhu.engr.sgi.com
Mar Ene 25 22:49:03 CST 2000
On 21-Jan-2000 Ingo Molnar wrote:
>
> On 20 Jan 2000, Dimitris Michailidis wrote:
>
>> * fixes the bug that causes TASK_INTERRUPTIBLE|TASK_EXCLUSIVE processes
>> to be taken off the run queue even if they have pending signals;
>
>> * occasionally, a process that goes to sleep becomes runnable before it
>> is completely descheduled. For such processes the current scheduler runs
>
> yep these two are real bugs. What is the speed impact of your generic
> scheduler changes on 'lat_ctx -s 0 2', 'lat_ctx -s 0 100' & similar
> scheduler numbers? We do not have to care too much about the case when
> 1000 processes are running at once. (if we get performance in that area
> for free, then ok. If it hurts the simple case then no thanks.)
>
> -- mingo
Example lmbench numbers on a 4p box (take them with a grain of salt,
lmbench numbers fluctuate considerably between runs):
stock 2.3.40 2.3.40+patch
"size=0k ovr=3.80 "size=0k ovr=3.78
2 2.08 2 2.04
4 2.60 4 2.53
8 3.14 8 3.05
16 4.64 16 3.12
24 5.21 24 3.83
32 4.01 32 4.59
64 5.25 64 6.18
96 5.29 96 6.49
"size=4k ovr=5.92 "size=4k ovr=5.83
2 2.64 2 2.69
4 4.63 4 4.73
8 5.72 8 5.76
16 6.05 16 6.50
24 7.10 24 7.24
32 7.24 32 9.17
64 9.53 64 9.83
96 11.59 96 12.00
"size=8k ovr=7.93 "size=8k ovr=7.89
2 5.21 2 5.30
4 8.23 4 8.54
8 8.31 8 8.58
16 10.10 16 9.72
24 10.34 24 13.37
32 11.40 32 13.86
64 17.70 64 18.57
96 20.50 96 24.24
"size=16k ovr=12.08 "size=16k ovr=12.03
2 14.23 2 14.39
4 14.15 4 14.32
8 18.41 8 20.32
16 23.31 16 22.98
24 24.07 24 27.58
32 24.28 32 30.30
64 49.33 64 54.57
96 60.57 96 61.17
"size=32k ovr=20.28 "size=32k ovr=20.28
2 23.10 2 23.31
4 29.16 4 23.28
8 29.77 8 32.32
16 36.43 16 38.82
24 43.89 24 44.59
32 62.52 32 61.78
64 98.44 64 99.85
96 108.63 96 109.19
"size=64k ovr=36.83 "size=64k ovr=36.75
2 45.44 2 45.19
4 47.28 4 54.46
8 61.64 8 84.96
16 99.05 16 103.52
24 118.65 24 154.47
32 154.21 32 168.41
64 211.59 64 207.92
96 215.62 96 214.51
Other tests I tried were always faster with the patch. Examples:
Kernel build (make -j 4), three runs on each kernel, first run on a clean
2.3.40 tree after a reboot, subsequent runs following make clean:
stock 2.3.40
281.84user 20.06system 1:22.64elapsed
280.28user 18.89system 1:17.69elapsed
280.16user 18.61system 1:17.80elapsed
2.3.40 + patch
278.23user 19.84system 1:22.42elapsed
277.21user 18.53system 1:17.12elapsed
276.73user 18.94system 1:17.32elapsed
dbench 16
2.3.40
Throughput 131.942 MB/sec (NB=164.927 MB/sec 1319.42 MBit/sec)
13.32user 41.48system 0:17.01elapsed
2.3.40 + patch
Throughput 152.697 MB/sec (NB=190.871 MB/sec 1526.97 MBit/sec)
12.83user 39.67system 0:14.83elapsed
For some reason dbench shows dramatic improvements in some cases, for
example on this machine dbench 32 on 2.3.40 took at least 70 secs on all
runs I tried, with the patch it usually finished in less than 30 secs. I'll
have to take a look at kernel traces to see what was happening.
--
Dimitris Michailidis dimitris en engr.sgi.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Más información sobre la lista de distribución Ayuda