BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 9:43 UTC (Mon) by russell (guest, #10458)
Parent article: BFS vs. mainline scheduler benchmarks and measurements

Every one of Ingo's tests is about throughput, not latency. Unless Ingo defines latency as the amount of time available to make coffee while a kernel build completes :)

Would be great if Con, et al, spent some time developing benchmarks that put numbers to how a desktop feels. That's probably the only way these conversations will stop diving into the ground on flames.

to post comments

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 10:28 UTC (Mon) by jamesh (guest, #1159) [Link] (2 responses)

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.

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).

Does the kernel scheduler even matter???

Posted Sep 7, 2009 11:05 UTC (Mon) by eru (subscriber, #2753) [Link] (3 responses)

It seems to me most of the desktop latencies stem from bloated desktop managers and other GUI software, and from bad graphics drivers. The kernel cannot fix these issues, no matter which scheduler it has. The question to ask is do the user interface really have to relay events through about 100 levels of complex libraries every time the user performs some action.

Does the kernel scheduler even matter???

Posted Sep 7, 2009 11:21 UTC (Mon) by mjthayer (guest, #39183) [Link] (2 responses)

Still, if (and I haven't actually done any tests here) the kernel can fix this in a reasonable way, why not do it?

Does the kernel scheduler even matter???

Posted Sep 7, 2009 13:46 UTC (Mon) by mingo (subscriber, #31122) [Link] (1 responses)

For many things the process scheduler does matter.

For most desktop things, the IO scheduler, the file system and the VM has a far bigger role.

To measure latencies, there's the latencytop tool from Arjan that can give a first-level guess about what the main source of latencies is.

If it's IO latencies then blktrace can be used to pin them down more precisely.

If it's indeed the process scheduler that is causing latencies, the latency tracer can be used to pin down the reason more precisely. On the lowest level the function tracer can be used too, for harder cases. There's also a lot of built-in statistics, tracepoints and in .31 based kernels also performance counters that can help in the pinning down of such bugs.

Does the kernel scheduler even matter???

Posted Sep 10, 2009 20:54 UTC (Thu) by ajb (subscriber, #9694) [Link]

The scheduler could still help more under conditions of VM stress. For example, on my netbook, which thrashes when you run firefox + anything, I literally run killall -STOP firefox-bin; killall -CONT other-app when I want to switch between them. This is a lot more convenient than quitting and restarting each app, which otherwise I would have to do. I imagine there might be some less manual way to achieve the same thing by building some more smarts into the scheduler/VM to achieve the same effect. Possibly with help from userspace.