O(1) scheduler gives big boost to tbench 192
Quoted 5 lines
BTW, Randy, I seen my tree runs slower with tiobench, that's probably because I made the elevator anti-starvation logic more aggressive than mainline and the other kernel trees (to help interactive usage), could you try to run tiobench on -aa after elvtune -r 8192 -w 16384 /dev/hd[abcd] to verify? Thanks for the great benchmarking effort.
I will have results on the big machine in a couple days. On the small machine, elvtune increases tiobench sequential reads by 30-50%, and lowers worst case latency a little.
More -aa at:
http://home.earthlink.net/~rwhron/kernel/aa.html
Quoted 3 lines
And for the reason fork is faster in -aa that's partly thanks to the reschedule-child-first logic, that can be easily merged in mainline, it's just in 2.5.
Is that part of parent_timeslice patch? parent_timeslice helped fork a little when I tried to isolating patches to find what makes fork faster in -aa. It is more than one patch as far as I can tell.
On uniprocessor the unixbench execl test, all -aa kernel's going back at least to 2.4.15aa1 are about 20% faster than other trees, even those like jam and akpm's splitted vm. Fork in -aa for more "real world" test (autoconf build) is about 8-10% over other kernel trees.
On quad Xeon, with bigger L2 cache, autoconf (fork test) the difference between mainline and -aa is smaller. The -aa based VMs in aa, jam, and mainline have about 15% edge over rmap VM in ac and rmap. jam has a slight advantage for autoconf build, possibly because of O(1) effect which is more likely to show up since more processes execute on the 4 way box.
More quad Xeon at:
http://home.earthlink.net/~rwhron/kernel/bigbox.html
Signature · 1 line
Randy Hron
Quoted 9 lines · On Mon, May 06, 2002 at 04:20:05AM -0400, [email protected] wrote:
Quoted 5 lines
BTW, Randy, I seen my tree runs slower with tiobench, that's probably because I made the elevator anti-starvation logic more aggressive than mainline and the other kernel trees (to help interactive usage), could you try to run tiobench on -aa after elvtune -r 8192 -w 16384 /dev/hd[abcd] to verify? Thanks for the great benchmarking effort.
I will have results on the big machine in a couple days. On the small machine, elvtune increases tiobench sequential reads by 30-50%, and lowers worst case latency a little.
ok, everything is fine then, thanks for the further benchmarks. Not sure if I should increase the elvtune defaults, the max latency with 8 reading threads literally doubles (from a mean of 500/600 to 1200). OTOH with 128 threads max latency even decreases (most probably because of higher mean throughput).
Quoted 5 lines
Quoted 3 lines
And for the reason fork is faster in -aa that's partly thanks to the reschedule-child-first logic, that can be easily merged in mainline, it's just in 2.5.
Is that part of
parent_timeslicepatch?parent_timeslicehelped
Yep.
Quoted 16 lines
fork a little when I tried to isolating patches to find what makes fork faster in -aa. It is more than one patch as far as I can tell.
On uniprocessor the unixbench execl test, all -aa kernel's going back at least to 2.4.15aa1 are about 20% faster than other trees, even those like jam and akpm's splitted vm. Fork in -aa for more "real world" test (autoconf build) is about 8-10% over other kernel trees.
On quad Xeon, with bigger L2 cache, autoconf (fork test) the difference between mainline and -aa is smaller. The -aa based VMs in aa, jam, and mainline have about 15% edge over rmap VM in ac and rmap. jam has a slight advantage for autoconf build, possibly because of O(1) effect which is more likely to show up since more processes execute on the 4 way box.
Quoted 6 lines
More quad Xeon at:
http://home.earthlink.net/~rwhron/kernel/bigbox.htmlSignature · 1 line
Randy Hron
Andrea