Hi Ingo,
  Did a test with massive_intr.c on a standard linux desktop.
for vanilla, con's Sd-0.40 and cfs.

Test bed is a p4 2.26GHz, 512mb ram
No load on the machine expect for the X server.

Results are stated below

Vanilla Kernel=20
--------------------
2.6.21-rc6-vanilla #8 SMP Sat Apr 14=20

[surya@bluegenie tests]$ ./massive_intr 10 10
002469  00000548
002463  00000499
002464  00000026
002465  00000028
002472  00000021
002467  00000018
002470  00000015
002466  00000017
002468  00000024
002471  00000013

top output
top - 13:49:53 up 4 min,  3 users,  load average: 1.24, 0.71, 0.30
Tasks:  80 total,  10 running,  70 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.3%us,  1.8%sy,  0.0%ni, 72.1%id, 12.7%wa,  0.1%hi,  0.0%si,
0.0%st
Mem:    506112k total,   440980k used,    65132k free,    31444k buffers
Swap:   522104k total,        0k used,   522104k free,   309560k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+
COMMAND           =20
 2469 surya     16   0  1624  204  132 S 33.8  0.0   0:00.30
massive_intr      =20
 2467 surya     22   0  1624  204  132 R 19.9  0.0   0:00.20
massive_intr      =20
 2466 surya     23   0  1624  204  132 R 15.9  0.0   0:00.20
massive_intr      =20
 2470 surya     24   0  1624  204  132 R 13.9  0.0   0:00.18
massive_intr      =20
 2468 surya     19   0  1624  204  132 R  8.0  0.0   0:00.19
massive_intr      =20
 2463 surya     19   0  1624  204  132 R  6.0  0.0   0:00.26
massive_intr      =20
    1 root      15   0  2032  640  548 S  0.0  0.1   0:00.72=20
 bash              =20
<snip>
 2462 surya     25   0  1624  428  356 S  0.0  0.1   0:01.63
massive_intr      =20
 2464 surya     20   0  1624  204  132 R  0.0  0.0   0:00.21
massive_intr      =20
 2465 surya     21   0  1624  204  132 R  0.0  0.0   0:00.20
massive_intr      =20
 2471 surya     20   0  1624  204  132 R  0.0  0.0   0:00.10
massive_intr      =20
 2472 surya     21   0  1624  204  132 R  0.0  0.0   0:00.20
massive_intr      =20
 2473 ...
[ message continues ]

Hi Surya,

On Sat, Apr 14, 2007 at 02:19:06PM +0530, surya.prabhakar@wipro.com wrote:
(...)

It looks like Ingo can do very good things, he just needs very strong
competition to decide to go to the keyboard ;-)

Sorta like lazy sportives who decide to make an effort at the last
moment not to lose their first place...

Cheers,
Willy

-

[ message continues ]

btw., other schedulers might work better with some more test-time: i'd 
suggest to use 60 seconds (./massive_intr 10 60) [or maybe more, using 

cool. ringtest.c is intended to be used the following way: start it, it 
will generate a 99% busy system (but it is using a ring of 100 tasks, 
where each tasks runs for 100 msecs then sleeps for 1 msec, so every 
task gets a turn every 10 seconds). If you add a pure CPU hog to the 
system, for example an infinite shell loop:

	while :; do :; done &

then a 'fair' scheduler would give roughly 50% of CPU time to the CPU 
hog (and the ringtest.c tasks take up the other 50%).

	Ingo
-

[ message continues ]

I've queued up modifying ringtest.c to automatically spawn a CPU hog
and then report aggregate CPU bandwidth of the ring and the bandwidth
of the CPU hog as work to do at some point. I've no guarantee I'll get
to it in a timely fashion, though.


-- wli
-

[ message continues ]

At Sat, 14 Apr 2007 14:02:20 +0200,

I tested CFS with massive_intr. I did long term, many CPUs, and many
processes cases.

Test environment
================

 - kernel:         2.6.21-rc6-CFS
 - run time:       300 secs
 - # of CPU:       1 or 4
 - # of processes: 200 or 800

Result
======

  +---------+-----------+-------+------+------+--------+
  |   # of  |   # of    | avg   | max  | min  |  stdev |
  |   CPUs  | processes | (*1)  | (*2) | (*3) |  (*4)  |
  +---------+-----------+-------+------+------+--------+
  | 1(i386) |           | 117.9 |  123 |  115 |    1.2 |
  +---------|       200 +-------+------+------+--------+
  |         |           | 750.2 |  767 |  735 |   10.6 |
  | 4(ia64) +-----------+-------+------+------+--------+
  |         |   800(*5) | 187.3 |  189 |  186 |    0.8 |
  +---------+-----------+-------+------+------+--------+

  *1) average number of loops among all processes
  *2) maximum number of loops among all processes
  *3) minimum number of loops among all processes
  *4) standard deviation
  *5) Its # of processes per CPU is equal to first test case.

Pretty good! CFS seems to be fair in any situation.

Satoru
-

[ message continues ]

thanks for testing this! Indeed the min-max values and standard 
deviation look all pretty healthy. (They in fact seem to be better than 
the other patch of mine against upstream that you tested, correct?)

[ And there's also another nice little detail in your feedback: CFS
  actually builds, boots and works fine on ia64 too ;-) ]

	Ingo
-

[ message continues ]

At Mon, 16 Apr 2007 10:47:25 +0200,

Is it?

patch:
http://lkml.org/lkml/2007/3/27/225

test result:
http://lkml.org/lkml/2007/3/31/41


You are welcome. I can use larger machine by chance, and also tested
there just now.

Test environment
================

 - kernel:         2.6.21-rc6-CFS
 - run time:       300 secs
 - # of CPU:       12
 - # of processes: 200 or 2400

Result
===================================

  +----------+-----------+-------+------+------+--------+
  |   # of   |   # of    | avg   | max  | min  |  stdev |
  |   CPUs   | processes |       |      |      |        |
  +----------+-----------+-------+------+------+--------+
  |          |       200 |  2250 | 2348 | 2204 |     64 |
  | 12(ia64) +-----------+-------+------+------+--------+
  |          |      2400 | 187.5 |  197 |  176 |    4.3 |
  +----------+-----------+-------+------+------+--------+

Looks like good too.


BTW, I've a question. Actually this problem is fixed on CFS and DS. However
they are mostly written from scratch and doeesn't suitable for stable version,
for example 2.6.20.X. Can your other patch be compromise for stable version?
Although that patch is not perfect, but I think it's preferable to leave it
alone.

Satoru
-

[ message continues ]

yeah. The spread between min and max is 11%, the spread between stddev 

i'm afraid that small patch is not suitable for a general purpose Linux 
release (it hits interactivity way too much) - that's what this 
years-long struggle was about. But you could apply it to a special 
server-centric kernel.

	Ingo
-

[ message continues ]