lkml.org 
[lkml]   [1999]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.050 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site