3 ms·

You cannot "fix" the kernel. Fundamentally, the owner of spinlock can get preempted for a large number of different reasons, and in such a case, the spinlock wi

You cannot "fix" the kernel. Fundamentally, the owner of spinlock can get preempted for a large number of different reasons, and in such a case, the spinlock will spin until the owning thread gets scheduled and runs again. The kernel can't prioritize re-scheduling the owning thread because it doesn't know that some other thread is waiting on that thread. Fundamentally, you need to tell the kernel what you're doing so it can help you. There's no fix here.

shadowgovt 7y ago
It's software; it can always be fixed. ;) And given the over-arching topic of performance in Stadia, it may behoove Google to fork Linux and specialize the scheduler implementation to be more spinlock-friendly. Especially if Linux's benevolent dictator for life is telegraphing he doesn't consider it an interesting problem to solve.
- quotemstr 7y ago
  > It's software; it can always be fixed. ;) No, it cannot be fixed, because the kernel simply does not have enough information in the case of naive spin locks to make good scheduling decisions. I understand the Chesterton's-fence argument in favor of learning why game developers use spin locks before telling them to do something else, but in this case, I really think simple ignorance is the most likely explanation. You never want a spinlock in userspace. Period. An adaptive mutex will give you what you want without the pathological downsides. Look: your whole line of reasoning here is just bizarre and invalid. You can't say "well, maybe there's a reason they're doing it!" without actually backing this claim up with specific reasoning. Sorry, but you can't keep using your spinlocks even if they "work" on other platforms. If they "work" there, it's an accident.
  - shadowgovt 7y ago
    > You never want a spinlock in userspace What if you've already used them in code that runs in N other architectures, the game works fine in those architectures, and Linux is architecture N+1, which you're trying to decide to support or not? The less the code has to be changed, the easier it is to support architecture N+1.
  - jcranmer 7y ago
    > No, it cannot be fixed If it cannot be fixed, then why is it only a problem for Linux?
    - gpderetta 7y ago
      It can obviously be "fixed", but the problem is that it might regress other loads that have been tuned for the current behaviour.
    - bryanlarsen 7y ago
      I imagine it's a problem on all operating systems trying to run multiple games or other heavy+responsive workloads simultaneously.

shadowgovt 7y ago

It's software; it can always be fixed. ;) And given the over-arching topic of performance in Stadia, it may behoove Google to fork Linux and specialize the scheduler implementation to be more spinlock-friendly. Especially if Linux's benevolent dictator for life is telegraphing he doesn't consider it an interesting problem to solve.

quotemstr 7y ago
> It's software; it can always be fixed. ;) No, it cannot be fixed, because the kernel simply does not have enough information in the case of naive spin locks to make good scheduling decisions. I understand the Chesterton's-fence argument in favor of learning why game developers use spin locks before telling them to do something else, but in this case, I really think simple ignorance is the most likely explanation. You never want a spinlock in userspace. Period. An adaptive mutex will give you what you want without the pathological downsides. Look: your whole line of reasoning here is just bizarre and invalid. You can't say "well, maybe there's a reason they're doing it!" without actually backing this claim up with specific reasoning. Sorry, but you can't keep using your spinlocks even if they "work" on other platforms. If they "work" there, it's an accident.
- shadowgovt 7y ago
  > You never want a spinlock in userspace What if you've already used them in code that runs in N other architectures, the game works fine in those architectures, and Linux is architecture N+1, which you're trying to decide to support or not? The less the code has to be changed, the easier it is to support architecture N+1.
- jcranmer 7y ago
  > No, it cannot be fixed If it cannot be fixed, then why is it only a problem for Linux?
  - gpderetta 7y ago
    It can obviously be "fixed", but the problem is that it might regress other loads that have been tuned for the current behaviour.
  - bryanlarsen 7y ago
    I imagine it's a problem on all operating systems trying to run multiple games or other heavy+responsive workloads simultaneously.