5 ms·

Ingo Molnar: BFS vs. mainline scheduler benchmarks and measurements

40 points by blasdel 17y ago

peregrine 17y ago
On a related thread http://news.ycombinator.com/item?id=810833 http://news.ycombinator.com/item?id=810833 BFS had been ported to one of the Custom Roms for Android and has already shown increased speed improvements.
blasdel 17y ago
The parallel LWN thread: http://lwn.net/Articles/351058/ http://lwn.net/Articles/351058/
- nitrogen 17y ago
  A lot of discussion on LWN and on the LKML seems to focus on the "unbenchmarkability" of UI interactiveness. This is just a guess, but maybe Con's background as an anesthesiologist (rather than a programmer) causes him to understand feelings better than measurements. If I were to assign blame for the latency problems I experience, I would place it on the 100-call-deep stacks that are used to deliver events in Gtk+ and Qt, and on the binary Nvidia driver's lack of good 2D+compositing acceleration.
  - rbanffy 17y ago
    "Con's background as an anesthesiologist (rather than a programmer) causes him to understand feelings better than measurements" I would be pretty worried with an anesthesiologist that disregarded his measurements... Either you can measure or it doesn't exist. If it exists and you don't measure, you'd better write something to measure it.
  - jacquesm 17y ago
    If there is ONE job where your ability to measure means the difference between life and death than it is being an anesthesiologist.
dfranke 17y ago
I think CK's reply just put me off for good from taking the time to try out his patches: /me sees Ingo run off to find the right combination of hardware and benchmark to prove his point. [snip lots of bullshit meaningless benchmarks showing how great cfs is and/or how bad bfs is, along with telling people they should use these artificial benchmarks to determine how good it is, demonstrating yet again why benchmarks fail the desktop] So, to paraphrase: BFS is vastly superior, but not in any way that you can actually measure. Con made a valuable contribution back when the choice was between staircase-deadline and the old mainline O(1) scheduler, but he's since turned himself into a crank.
- spamizbad 17y ago
  Yeah, CK came across as a major dick, but... Ingo benched this on a two-socket, 8-CPU system. CK made it blatantly obvious he was targeting single-socket multi-core systems, or UMA SMP systems. Further, he's seems pretty adamant about not tweaking the scheduler for anything beyond single-socket multicore or UMA SMP, to say nothing of more exotic CPU/Memory architectures.
  - neilc 17y ago
    Building a scheduler that doesn't scale to an 8-CPU system seems like madness to me, given the very predictable trends in desktop hardware.
    - wmf 17y ago
      The cost of bouncing a cache line depends less on the number of cores and more on the number of sockets. Since the future of desktops is clearly 1-socket machines, BFS is optimized for that and it's not representative to test with a 2-socket machine. IOW, today's expensive 8-core 2S workstation is not a good proxy for tomorrow's cheap 8-core 1S desktop.
      - neilc 17y ago
        Interesting point -- I've never written a scheduler. Is it really true that writing a scheduler for the multi-socket, multi-core case is that much more complicated than focusing on single-socket, multi-core? Seems possible to me. However, doesn't the existence of hyperthreading contradict that? Even for the single-socket, multi-core case, you need to account for the fact that the virtual processors are not identical.
skorgu 17y ago
I'm not going to try to follow LKML just for this but if anyone at HN has a benchmark they'd like me to try out on 2.6.30 Arch vs 2.6.30-bfs on a quad-core Xeon I'll give it a shot.
- illumen 17y ago
  Run a compile job, or a video encode... then try web browsing. Perhaps you could time clicks to open new tabs in your browser. Or switch virtual spaces. With the background work, you should notice no or very little difference. Since the interactive work should get highest priority(this is what you are aiming for). You can try these tests without bfs patches too. You can see how the default kernel/X11/driver is not optimal - and how things can be improved. It's still much nicer than OSX, and windows however.
  - skorgu 17y ago
    Yeah, I've done the standard "nice make -j 4 bzImage" and noticed no detectable slowdown in normal browsing tasks, window movement, chromium/flashplayer etc. It does feel snappier as CK was going for but since I know I'm running bfs I'm somewhat afraid of confirmation bias.
psranga 17y ago
I would LOVE to use a scheduler tuned for my hardware if outperformed the generic scheduler. I'm not a kernel developer, but I can imagine how the mainstream single-socket multicore case may be quite different from the multi-socket multicore case. As I software engineer, I realize that making different schedulers for different architectures is "inefficient" (unless development/test resources are increased). But if somebody is willing to put in the time and effort to make me a scheduler that works best on my hardware, I'll gladly take it. I have to agree with Con's remarks here. Seems like an underhanded move by Ingo to give this thing a bad reputation (and hence kill developer and beta tester interest) before it comes out. And judging by the comments here, he may have succeeded. Looks like open source has lots of politics too. :)
- dfranke 17y ago
  I don't think I quite understand what misconception people hold which leads them to believe that any environment in which two or more human beings are in social contact could ever be free of politics.

40 points by blasdel 17y ago

On a related thread http://news.ycombinator.com/item?id=810833 http://news.ycombinator.com/item?id=810833 BFS had been ported to one of the Custom Roms for Android and has already shown increased speed improvements.

blasdel 17y ago

The parallel LWN thread: http://lwn.net/Articles/351058/ http://lwn.net/Articles/351058/

nitrogen 17y ago
A lot of discussion on LWN and on the LKML seems to focus on the "unbenchmarkability" of UI interactiveness. This is just a guess, but maybe Con's background as an anesthesiologist (rather than a programmer) causes him to understand feelings better than measurements. If I were to assign blame for the latency problems I experience, I would place it on the 100-call-deep stacks that are used to deliver events in Gtk+ and Qt, and on the binary Nvidia driver's lack of good 2D+compositing acceleration.
- rbanffy 17y ago
  "Con's background as an anesthesiologist (rather than a programmer) causes him to understand feelings better than measurements" I would be pretty worried with an anesthesiologist that disregarded his measurements... Either you can measure or it doesn't exist. If it exists and you don't measure, you'd better write something to measure it.
- jacquesm 17y ago
  If there is ONE job where your ability to measure means the difference between life and death than it is being an anesthesiologist.

dfranke 17y ago

I think CK's reply just put me off for good from taking the time to try out his patches: /me sees Ingo run off to find the right combination of hardware and benchmark to prove his point. [snip lots of bullshit meaningless benchmarks showing how great cfs is and/or how bad bfs is, along with telling people they should use these artificial benchmarks to determine how good it is, demonstrating yet again why benchmarks fail the desktop] So, to paraphrase: BFS is vastly superior, but not in any way that you can actually measure. Con made a valuable contribution back when the choice was between staircase-deadline and the old mainline O(1) scheduler, but he's since turned himself into a crank.

spamizbad 17y ago
Yeah, CK came across as a major dick, but... Ingo benched this on a two-socket, 8-CPU system. CK made it blatantly obvious he was targeting single-socket multi-core systems, or UMA SMP systems. Further, he's seems pretty adamant about not tweaking the scheduler for anything beyond single-socket multicore or UMA SMP, to say nothing of more exotic CPU/Memory architectures.
- neilc 17y ago
  Building a scheduler that doesn't scale to an 8-CPU system seems like madness to me, given the very predictable trends in desktop hardware.
  - wmf 17y ago
    The cost of bouncing a cache line depends less on the number of cores and more on the number of sockets. Since the future of desktops is clearly 1-socket machines, BFS is optimized for that and it's not representative to test with a 2-socket machine. IOW, today's expensive 8-core 2S workstation is not a good proxy for tomorrow's cheap 8-core 1S desktop.
    - neilc 17y ago
      Interesting point -- I've never written a scheduler. Is it really true that writing a scheduler for the multi-socket, multi-core case is that much more complicated than focusing on single-socket, multi-core? Seems possible to me. However, doesn't the existence of hyperthreading contradict that? Even for the single-socket, multi-core case, you need to account for the fact that the virtual processors are not identical.

skorgu 17y ago

I'm not going to try to follow LKML just for this but if anyone at HN has a benchmark they'd like me to try out on 2.6.30 Arch vs 2.6.30-bfs on a quad-core Xeon I'll give it a shot.

illumen 17y ago
Run a compile job, or a video encode... then try web browsing. Perhaps you could time clicks to open new tabs in your browser. Or switch virtual spaces. With the background work, you should notice no or very little difference. Since the interactive work should get highest priority(this is what you are aiming for). You can try these tests without bfs patches too. You can see how the default kernel/X11/driver is not optimal - and how things can be improved. It's still much nicer than OSX, and windows however.
- skorgu 17y ago
  Yeah, I've done the standard "nice make -j 4 bzImage" and noticed no detectable slowdown in normal browsing tasks, window movement, chromium/flashplayer etc. It does feel snappier as CK was going for but since I know I'm running bfs I'm somewhat afraid of confirmation bias.

psranga 17y ago

I would LOVE to use a scheduler tuned for my hardware if outperformed the generic scheduler. I'm not a kernel developer, but I can imagine how the mainstream single-socket multicore case may be quite different from the multi-socket multicore case. As I software engineer, I realize that making different schedulers for different architectures is "inefficient" (unless development/test resources are increased). But if somebody is willing to put in the time and effort to make me a scheduler that works best on my hardware, I'll gladly take it. I have to agree with Con's remarks here. Seems like an underhanded move by Ingo to give this thing a bad reputation (and hence kill developer and beta tester interest) before it comes out. And judging by the comments here, he may have succeeded. Looks like open source has lots of politics too. :)

dfranke 17y ago
I don't think I quite understand what misconception people hold which leads them to believe that any environment in which two or more human beings are in social contact could ever be free of politics.