4 ms·

No, there are not good reasons to use spinlocks in userland. Period. Even in a game. You always have the spinning while preempted problem. You can't blame a pre

No, there are not good reasons to use spinlocks in userland. Period. Even in a game. You always have the spinning while preempted problem. You can't blame a preempting operating system for preempting! Any situation you rig up where you don't preempt is very fragile. What you can do is make mutexes perfectly adaptive so that they switch to a blocking wait as soon as the lock owner itself gets preempted. I have a proposal to do that here: https://lore.kernel.org/lkml/CAKOZuesa338sc_=w6-wvro25idrSN_zx_zrHFyo-bDiORs7FZw@mail.gmail.com/ https://lore.kernel.org/lkml/CAKOZuesa338sc_=w6-wvro25idrSN_... You should always use waiting primitives when possible instead of just spinning. If you tell the kernel what you're doing, the kernel can help you. If you hide the wait DAG from the kernel, it can't.

shadowgovt 7y ago
Unfortunately, texts on the topic of game engine development disagree with your assertion (https://books.google.com/books?id=1g1mDwAAQBAJ&pg=PA319&lpg=PA319#v=onepage&q&f=false https://books.google.com/books?id=1g1mDwAAQBAJ&pg=PA319&lpg=...). If people are learning bad practice from the texts, and the bad practice hits Linux's scheduler asymmetrically hard (relative to other game platforms), one can expect outsized impact on the performance of games atop Linux architectures.
- rbanffy 7y ago
  > texts on the topic of game engine development disagree with your assertion We may need updated books.
- cryptonector 7y ago
  Oh no! I guess the Linux kernel will need a fix then! Those texts can't be wrong!
  - shadowgovt 7y ago
    This is where technology meets social network effect. Which is easier (modifying the scheduler for better spinlock support or get developers to stop using spinlock when it's easy to implement and works in other OS targets) is an open question. "Don't use spinlock" is like "the user is holding it wrong" for API. The user can either choose to modify their behavior or throw up their hands and not port to Linux.
    - quotemstr 7y ago
      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.
- quotemstr 7y ago
  Those books are wrong and dangerous. There's no other way to describe the situation: they advocate a technique that's both counterproductive and detrimental to game and system performance.
  - shadowgovt 7y ago
    Universally? Or just on the OSes you're familiar with? It may be useful to explore why they teach those techniques before passing judgement on a whole ecosystem of educational material.

shadowgovt 7y ago

Unfortunately, texts on the topic of game engine development disagree with your assertion (https://books.google.com/books?id=1g1mDwAAQBAJ&pg=PA319&lpg=PA319#v=onepage&q&f=false https://books.google.com/books?id=1g1mDwAAQBAJ&pg=PA319&lpg=...). If people are learning bad practice from the texts, and the bad practice hits Linux's scheduler asymmetrically hard (relative to other game platforms), one can expect outsized impact on the performance of games atop Linux architectures.

rbanffy 7y ago
> texts on the topic of game engine development disagree with your assertion We may need updated books.
cryptonector 7y ago
Oh no! I guess the Linux kernel will need a fix then! Those texts can't be wrong!
- shadowgovt 7y ago
  This is where technology meets social network effect. Which is easier (modifying the scheduler for better spinlock support or get developers to stop using spinlock when it's easy to implement and works in other OS targets) is an open question. "Don't use spinlock" is like "the user is holding it wrong" for API. The user can either choose to modify their behavior or throw up their hands and not port to Linux.
  - quotemstr 7y ago
    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.
quotemstr 7y ago
Those books are wrong and dangerous. There's no other way to describe the situation: they advocate a technique that's both counterproductive and detrimental to game and system performance.
- shadowgovt 7y ago
  Universally? Or just on the OSes you're familiar with? It may be useful to explore why they teach those techniques before passing judgement on a whole ecosystem of educational material.