Randy Hron posted some benchmark results comparing numerous different 2.4 kernel branches. He says, "On an OSDL 4 way x86 box the O(1) scheduler effect becomes obvious as the run queue gets large."

Using tbench with 192 processes, his tests show the latest O(1) incarnation to offer approximately a 340% improvement in throughput! (Both Alan Cox's -ac patch and J.A. Magallon's -jam patch set include the latest O(1) scheduler, and both show the dramatic improvement in throughput) Randy intends to do more testing, the results of which will be posted here.

From: Randy Hron
Subject: O(1) scheduler gives big boost to tbench 192
Date: 	Thu, 2 May 2002 17:36:56 -0400

On an OSDL 4 way x86 box the O(1) scheduler effect 
becomes obvious as the run queue gets large.  

2.4.19-pre7-ac2 and 2.4.19-pre7-jam6 have the O(1) scheduler.  

At 192 processes, O(1) shows about 340% improvement in throughput.
The dyn-sched in -aa appears to be somewhat improved over the
standard scheduler.

Numbers are in MB/second.
tbench 192 processes
2.4.16                    29.39
2.4.17                    29.70
2.4.19-pre5               29.01
2.4.19-pre5-aa1           29.22
2.4.19-pre5-aa1-2g-hio    29.94
2.4.19-pre5-aa1-3g-hio    28.66
2.4.19-pre7               29.93
2.4.19-pre7-aa1           32.75
2.4.19-pre7-ac2          103.98
2.4.19-pre7-rmap13        29.46
2.4.19-pre7-jam6         104.98
2.4.19-pre7-rl            29.74
At 64 processes, O(1) helps a little.  ac2 and jam6 have

the highest numbers here too.
tbench 64 processes
2.4.16                    101.99
2.4.17                    103.49
2.4.19-pre5-aa1           102.43
2.4.19-pre5-aa1-2g-hio    104.30
2.4.19-pre5-aa1-3g-hio    104.60
2.4.19-pre7               100.86
2.4.19-pre7-aa1           101.76
2.4.19-pre7-ac2           105.89
2.4.19-pre7-rmap13        100.94
2.4.19-pre7-rl             99.65
2.4.19-pre7-jam6          108.23
I've seen some benefit on a uniprocessor box running tbench 32

for kernels with O(1).  Hmm, have to try tbench 192 on uniproc

and see if the difference is all scheduler overhead.
I'm putting together a page with more results on this machine.

It will be growing at:

http://home.earthlink.net/~rwhron/kernel/bigbox.html
--

Randy Hron
From: Gerrit Huizenga

Subject: Re: O(1) scheduler gives big boost to tbench 192

Date: 	Thu, 02 May 2002 17:09:05 -0700
If you are bored, you might compare this to the MQ scheduler

at http://prdownloads.sourceforge.net/lse/2.4.14.mq-sched
Also, I think rml did a backport of the 2.5.X version of O(1);

I'm not sure if htat is in -ac or -jam as yet.
Rumor is that on some workloads MQ it outperforms O(1), but it

may be that the latest (post K3?) O(1) is catching up?
gerrit
From: J.A. Magallon

Subject: Re: O(1) scheduler gives big boost to tbench 192

Date: 	Fri, 3 May 2002 01:17:51 +0200
On 2002.05.03 Gerrit Huizenga wrote:

>Also, I think rml did a backport of the 2.5.X version of O(1);

>I'm not sure if that is in -ac or -jam as yet.

>
-jam6 is sched-O1-rml-2 (the backport).
--

J.A. Magallon                           #  Let the source be with you...

[email blocked]

Mandrake Linux release 8.3 (Cooker) for i586

Linux werewolf 2.4.19-pre7-jam9 #2 SMP mi� may 1 12:09:38 CEST 2002 i686
From: Alan Cox

Subject: Re: O(1) scheduler gives big boost to tbench 192

Date: 	Fri, 3 May 2002 01:14:19 +0100 (BST)
> If you are bored, you might compare this to the MQ scheduler

> at http://prdownloads.sourceforge.net/lse/2.4.14.mq-sched

>

> Also, I think rml did a backport of the 2.5.X version of O(1);

> I'm not sure if htat is in -ac or -jam as yet.
-ac has Robert Love's backport of the additional fixes
> Rumor is that on some workloads MQ it outperforms O(1), but it

> may be that the latest (post K3?) O(1) is catching up?
I'd be interested to know what workloads ?
From: Gerrit Huizenga

Subject: Re: O(1) scheduler gives big boost to tbench 192

Date: 	Thu, 02 May 2002 18:08:54 -0700
In message Alan Cox writes:

> > Rumor is that on some workloads MQ it outperforms O(1), but it

> > may be that the latest (post K3?) O(1) is catching up?

>

> I'd be interested to know what workloads ?
AIM on large CPU count machines was the most significant I had heard

about.  Haven't measured recently on database load - we made a cut to

O(1) some time back for simplicity.  Supposedly volanomark was doing

better for a while but again we haven't cut back to MQ in quite a while;

trying instead to refine O(1).  Volanomark is something of a scheduling

anomaly though - sender/receiver timing on loopback affects scheduling

decisions and overall throughput in ways that may or may not be consistent

with real workloads.  AIM is probably a better workload for "real life"

random scheduling testing.
gerrit