BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 10:28 UTC (Mon) by jamesh (guest, #1159)
In reply to: BFS vs. mainline scheduler benchmarks and measurements by russell
Parent article: BFS vs. mainline scheduler benchmarks and measurements

The pipe test looks like it is entirely about latency rather than throughput. It has two processes that wait on each other in an alternating fashion.

Scoring well on that benchmark will depend heavily on the average latency of the scheduler. Unfortunately it doesn't tell you the variance in the latency.

The benchmark Jens Axboe suggested (http://thread.gmane.org/gmane.linux.kernel/886319/focus=8...) might do the trick in measuring that though.

to post comments

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 10, 2009 4:01 UTC (Thu) by russell (guest, #10458) [Link] (1 responses)

The pipe test would work best if the scheduler gave each task sufficient time to fill or empty the pipe, depending on it's role. It would suffer badly if it kept preempting those tasks to give some other task a go when it became runnable.

The pipe test is more about ordering producers and consumers. Not latency.

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 10, 2009 5:18 UTC (Thu) by jamesh (guest, #1159) [Link]

In the pipe test, neither process is going to be able to fill the pipe buffer. Each process blocks on the other doing alternating reads and writes on the pipes with pretty much no work in between.

I guess it is possible that a scheduler could preempt the task between when the read returns and before it performs the write, but that seems unlikely.

My intuition is that performance would primarily depend on how quickly the scheduler gets round to run a process when it becomes unblocked, which is essentially a measure of average scheduling latency (and as I said before, this doesn't tell you much about the variance in that latency).