On Tue, 25 Jan 2000, Davide Libenzi wrote:
> > if you dynamicly change from one to the other how can you benchmark the
> > two to see where the proper place to switch over is? Also the test that
> > you have in to use one or the other is pure overhead, for benchmarking it
> > would be better to have two kernels, one with each scheduler and no test
> > to choose between them.
>
> Even if the patch must be evaluated for a relative high number of processes
> in RQ
> I'd like to measure the global patch with conventional benchmarks.
>
I think I was unclear again.
I was not meaning that you should create a special benchmark.
I was meaning that you should run two passes for the benchmark you are
using.
pass 1. standard kernel (or standard kernel with re-ordering patch
applied)
pass 2 new scheduler (or new scheduler with re-ordering patch applied)
The new scheduler for pass 2 should not be the one that switched between
the two algorithms, it should be just the new algorithm.
After you can tell where the performance lines cross then you can do a
pass 3 that dynamicly switches between the two and see how much that
suffers compared to pass 1 (it _will_ suffer becouse you have to run the
test to see if you should switch to the new algorithm)`
personally I have my doubts as to the value of dynamicly changing from one
to the other, I think the value of the new scheduler will be on machines
with many CPUs where you _do_ legitamatly have longer run queues and there
you can compile it in becouse if you have a run queue shorter then the
number of CPUs that you have you have an idle CPU that can run the
scheduler with no loss
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:15 EST