6 ms·

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 be

by 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.
      - wmf 17y ago
        I don't know that it's a matter of difficulty, just design tradeoffs. For a single socket you can probably get away with a single runqueue; there will be contention but it won't be that expensive. For multi-socket you want to have multiple runqueues; this scales better but you have to load balance threads between queues.
        jacquesm 17y ago
        And there are affinity issues to consider as well. Writing a scheduler is not for the faint of heart. What bothers me about this whole affair is that the egos of both parties seem to preclude them from working together to get to a 'best of breed' situation. Both Con & Ingo have a huge NIH problem.
  - joeyo 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. Even if that is true, it might make sense in other settings. On linux powered cell phones, for example.
    - nailer 17y ago
      Yep. http://twitter.com/cyanogen http://twitter.com/cyanogen
- dfranke 17y ago
  > two-socket, 8-CPU system Which is exactly the kind of machine that I'm sitting in front of at this very moment and have owned for more than two years. I realize this puts me on the leading edge, but any scheduler that can't cope with this in a reasonable manner is a bit of a joke.
  - skorgu 17y ago
    "Can't cope" may be overstating it, I parsed it as "not optimized for" which sounds fair.
- blasdel 17y ago
  http://thread.gmane.org/gmane.linux.kernel/886535 http://thread.gmane.org/gmane.linux.kernel/886535 He did it again on a single-socket 4-CPU system with HT. He got relatively the same results, including the curious marginal win for BFS on kbuild -jN where N == the # of logical processors.
tsally 17y ago
So, to paraphrase: BFS is vastly superior, but not in any way that you can actually measure. From my understanding, your interpretation is not correct. BFS is about latency, not throughput. Ingo chose all the wrong benchmarks. Also, it's a dick move by Ingo. CK hasn't even made a public announcement about BFS yet. Finally, you should use code that has technical merit, regardless of the personality behind the writer. I imagine the kernel you're running on has code in it written by some pretty unfriendly people.
- wmf 17y ago
  It's not that Ingo chose the wrong benchmarks. The right benchmarks don't exist, and we're not even sure how to build them. Unfortunately, building a scheduler optimized for "unbenchmarkable" use cases is a recipe for misunderstanding.
  - tsally 17y ago
    The right benchmarks for the stated goals of BFS do exist. BFS is hardly "unbemchmarkable"; the only thing being misunderstood here is the goal of BFS.
- dfranke 17y ago
  From my understanding, your interpretation is not correct. BFS is about latency, not throughput. Ingo chose all the wrong benchmarks. Then how about CK showing up the right ones? Also, it's a dick move by Ingo. CK hasn't even made a public announcement about BFS yet. He announced it publicly enough that I knew about it, and I haven't followed this stuff in years. Given that, I hardly think that commenting on his efforts on LKML constitutes a premature "outing". Finally, you should use code that has technical merit, regardless of the personality behind the writer. I imagine the kernel you're running on has code in it written by some pretty unfriendly people. Indeed: one of them murdered his wife. But you brought up personalities, not me. The part of CK's post that I quoted is rather dickish, but I deliberately avoided commenting on that.
  - tsally 17y ago

by dfranke 17y ago

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.
    - wmf 17y ago
      I don't know that it's a matter of difficulty, just design tradeoffs. For a single socket you can probably get away with a single runqueue; there will be contention but it won't be that expensive. For multi-socket you want to have multiple runqueues; this scales better but you have to load balance threads between queues.
      - jacquesm 17y ago
        And there are affinity issues to consider as well. Writing a scheduler is not for the faint of heart. What bothers me about this whole affair is that the egos of both parties seem to preclude them from working together to get to a 'best of breed' situation. Both Con & Ingo have a huge NIH problem.
- joeyo 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. Even if that is true, it might make sense in other settings. On linux powered cell phones, for example.
  - nailer 17y ago
    Yep. http://twitter.com/cyanogen http://twitter.com/cyanogen
dfranke 17y ago
> two-socket, 8-CPU system Which is exactly the kind of machine that I'm sitting in front of at this very moment and have owned for more than two years. I realize this puts me on the leading edge, but any scheduler that can't cope with this in a reasonable manner is a bit of a joke.
- skorgu 17y ago
  "Can't cope" may be overstating it, I parsed it as "not optimized for" which sounds fair.
blasdel 17y ago
http://thread.gmane.org/gmane.linux.kernel/886535 http://thread.gmane.org/gmane.linux.kernel/886535 He did it again on a single-socket 4-CPU system with HT. He got relatively the same results, including the curious marginal win for BFS on kbuild -jN where N == the # of logical processors.

tsally 17y ago

So, to paraphrase: BFS is vastly superior, but not in any way that you can actually measure. From my understanding, your interpretation is not correct. BFS is about latency, not throughput. Ingo chose all the wrong benchmarks. Also, it's a dick move by Ingo. CK hasn't even made a public announcement about BFS yet. Finally, you should use code that has technical merit, regardless of the personality behind the writer. I imagine the kernel you're running on has code in it written by some pretty unfriendly people.

wmf 17y ago
It's not that Ingo chose the wrong benchmarks. The right benchmarks don't exist, and we're not even sure how to build them. Unfortunately, building a scheduler optimized for "unbenchmarkable" use cases is a recipe for misunderstanding.
- tsally 17y ago
  The right benchmarks for the stated goals of BFS do exist. BFS is hardly "unbemchmarkable"; the only thing being misunderstood here is the goal of BFS.
dfranke 17y ago
From my understanding, your interpretation is not correct. BFS is about latency, not throughput. Ingo chose all the wrong benchmarks. Then how about CK showing up the right ones? Also, it's a dick move by Ingo. CK hasn't even made a public announcement about BFS yet. He announced it publicly enough that I knew about it, and I haven't followed this stuff in years. Given that, I hardly think that commenting on his efforts on LKML constitutes a premature "outing". Finally, you should use code that has technical merit, regardless of the personality behind the writer. I imagine the kernel you're running on has code in it written by some pretty unfriendly people. Indeed: one of them murdered his wife. But you brought up personalities, not me. The part of CK's post that I quoted is rather dickish, but I deliberately avoided commenting on that.
- tsally 17y ago