RE: a quest for a better scheduler

[Torrey Hoffman]

Timothy D. Witham wrote :
[...] 
> I propose that we work on setting up a straight forward test harness 
> that allows developers to quickly test a kernel patch against 
> various performance yardsticks.

[...
(proposed large server testbeds)
...]

I like this idea, but could the testbeds also include some 
resource-constrained "embedded" or appliance-style systems, and
include performance yardsticks for latency and responsiveness?

It would be unfortunate if work on a revised scheduler resulted
in Linux being a monster web server on 4-way systems, but having
lousy interactive performance on web pads, hand helds, and set top
boxes.  

How about a 120Mhz Pentium with 32MB of RAM and a flash disk, a 200 
Mhz PowerPC with 64 MB?  Maybe a Transmeta web pad?  

For the process load, something that tests responsiveness and 
latency - how about a set of processes doing multicast network 
transfers, CPU-intensive MPEG video and audio encode / decode,
and a test app that measures "user response", i.e. if X Windows 
was running, would the mouse pointer move smoothly or jerkily?

The "better" scheduler for these applications would make sure that 
multicast packets were never dropped, the MPEG decode never dropped 
frames, and the "user interface" stayed responsive, etc.

Also, I would not mind a bit if the kernel had tuning options, either 
in configuration or through /proc to adjust for these very different
situations.

Torrey Hoffman
[e-mail]