2 ms·

run an app that maps similar amount of work to N children and measure the run time ; measure the time needed for compiling [big project] with concurency These

run an app that maps similar amount of work to N children and measure the run time ; measure the time needed for compiling [big project] with concurency These are both the kind of tasks Kolivas is willing to totally throw under the bus for better worst case latency. Remember, the single goal of the project is to get worst-case latency for all non-cpu-limited processes on the system as low as it possibly can get. Throughput, and even best- and average case latency are considered entirely expendable. This is why the BFS is hard to benchmark.

mquander 17y ago
Actually, Kolivas states in the FAQ that compiling in particular is measured to be significantly faster with BFS: "For years we've been doing our workloads on linux to have more work than we had CPUs because we thought that the "jobservers" were limited in their ability to utilise the CPUs effectively (so we did make -j6 or more on a quad core machine for example). This scheduler proves that the jobservers weren't at fault at all, because make -j4 on a quad core machine with BFS is faster than any choice of job numbers on CFS." [1] [1] http://ck.kolivas.org/patches/bfs/bfs-faq.txt http://ck.kolivas.org/patches/bfs/bfs-faq.txt
scott_s 17y ago
Then measure worst case latency. I don't see what the difficulty is. If you're purporting to improve the performance of something, but you aren't always measuring the impact your changes have on the actual performance of that something, you're working blind.
nailer 17y ago
> Remember, the single goal of the project is to get worst-case latency for all non-cpu-limited processes on the system as low as it possibly can get. Throughput, and even best- and average case latency are considered entirely expendable. I've just been listing to lectures from MIT's introduction to algorithms, where more emphasis is placed on worst-case scenarios than otherwise, the reasoning being that these make guarantees possible. So more power to BFS.

mquander 17y ago

Actually, Kolivas states in the FAQ that compiling in particular is measured to be significantly faster with BFS: "For years we've been doing our workloads on linux to have more work than we had CPUs because we thought that the "jobservers" were limited in their ability to utilise the CPUs effectively (so we did make -j6 or more on a quad core machine for example). This scheduler proves that the jobservers weren't at fault at all, because make -j4 on a quad core machine with BFS is faster than any choice of job numbers on CFS." [1] [1] http://ck.kolivas.org/patches/bfs/bfs-faq.txt http://ck.kolivas.org/patches/bfs/bfs-faq.txt

scott_s 17y ago

Then measure worst case latency. I don't see what the difficulty is. If you're purporting to improve the performance of something, but you aren't always measuring the impact your changes have on the actual performance of that something, you're working blind.

nailer 17y ago

> Remember, the single goal of the project is to get worst-case latency for all non-cpu-limited processes on the system as low as it possibly can get. Throughput, and even best- and average case latency are considered entirely expendable. I've just been listing to lectures from MIT's introduction to algorithms, where more emphasis is placed on worst-case scenarios than otherwise, the reasoning being that these make guarantees possible. So more power to BFS.