Messages in this thread | | | Date | Mon, 10 May 1999 12:21:58 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [patch] new scheduler |
| |
On Sun, 9 May 1999, Jonathan Walther wrote:
> Its the priority recalculation in the scheduler thats the bottleneck as soon > as we hit 200 simultaneous processes. A MAJOR bottleneck. [...]
have you actually tried this? While i'm writing this email i'm also running 250 simultaneous CPU-hogs on 2.2.8-pre5:
10:57am up 25 min, 8 users, load average: 250.09, 242.75, 174.89 289 processes: 38 sleeping, 251 running, 0 zombie, 0 stopped CPU states: 399.7% user, 0.3% system, 0.0% nice, 0.0% idle Mem: 515636K av, 301564K used, 214072K free, 63356K shrd, 244364K buff Swap: 80320K av, 0K used, 80320K free 7400K cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 727 root 20 0 216 216 176 R 0 1.8 0.0 0:19 loop 785 root 20 0 216 216 176 R 0 1.8 0.0 0:18 loop 858 root 20 0 216 216 176 R 0 1.8 0.0 0:18 loop 931 root 20 0 216 216 176 R 0 1.8 0.0 0:17 loop 770 root 12 0 216 216 176 R 0 1.7 0.0 0:18 loop 818 root 16 0 216 216 176 R 0 1.7 0.0 0:18 loop
the system is not particularly fast (what would you expect from a system running 250 CPU hogs), but interactive performance is perfect. Bash prompt returns immediately, characters typed appear immediately. To quantify this, here is a 'ping' to another host on the network:
64 bytes from 195.4.7.3: icmp_seq=513 ttl=255 time=0.2 ms 64 bytes from 195.4.7.3: icmp_seq=514 ttl=255 time=0.2 ms 64 bytes from 195.4.7.3: icmp_seq=515 ttl=255 time=0.2 ms 64 bytes from 195.4.7.3: icmp_seq=516 ttl=255 time=0.2 ms 64 bytes from 195.4.7.3: icmp_seq=517 ttl=255 time=0.2 ms
this does not differ from what i get on a completely idle machine. ('ping' latencies are a good numeric indication of interactive performance, if interactive performance suffers then we also see bigger ping delays.)
the CPU hogs run at 'normal' priority, they are not reniced. Also note that only 0.3% CPU time is spent in the kernel. (readprofile shows that about 33% of that time is spent in the scheduler - no surprise here, the system does almost nothing else but runs the stupid CPU hog and reschedules. This means we spend 0.1% CPU time in the scheduler, which on this 4-CPU box is 0.025% of all available CPU time.)
[and if i run those CPU hogs with nice 20 then i do not notice _at all_ that the system is running 250 CPU hogs]
And this all is a rather stupid testcase with no RL significance IMO, designed to show alleged recalculation costs. Jonathan, WHERE is that 'MAJOR bottleneck'?
-- mingo
- 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/
| |