Messages in this thread | | | Date | Tue, 25 Jan 2000 16:37:29 -0800 (PST) | From | Dimitris Michailidis <> | Subject | Re: [RFC][PATCH] scheduler changes |
| |
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@engr.sgi.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |