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

Date: Mon May 06 2002 - 03:20:05 EST

> 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:

> 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:

Randy Hron

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at

This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:26 EST