3 ms·

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 mult

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.

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.