O(1) scheduler gives big boost to tbench 192
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
Signature · 1 line
Randy Hron
Quoted 11 lines · In message <20020502173656.A26986@rushmore>, > : [email protected] writes:
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.
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
Quoted 10 lines · On 2002.05.03 Gerrit Huizenga wrote:
Quoted 9 lines · In message <20020502173656.A26986@rushmore>, > : [email protected] writes:
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.
Quoted 9 lines
Quoted 2 lines
Numbers are in MB/second.
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.
-jam6 is sched-O1-rml-2 (the backport).
Quoted 3 lines
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?
Signature · 4 lines
J.A. Magallon # Let the source be with you... mailto:[email protected] 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
Quoted 5 lines
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
Quoted 2 lines
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 ?
Quoted 5 lines · In message <[email protected]>, > : Alan Cox writes:
Quoted 3 lines
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