By: Ricardo B (ricardo.b.delete@this.xxxxx.xx), August 17, 2014 6:43 am
Room: Moderated Discussions
anon (anon.delete@this.anon.com) on August 17, 2014 3:40 am wrote:
> Aaron Spink (aaronspink.delete@this.notearthlink.net) on August 17, 2014 12:42 am wrote:
>
> The point is that there is no minefield in going the *other* way. Maybe they create
> a minefield if they ever want to switch back, but if it is unquestioningly better
> to go with stronger ordering, then they have no barrier to make the transition.
Will make existing code/binaries run slower.
> > IIRC, Linus has commented on this topic in the past on this very board. They tend to be more conservative
> > with weakly ordered architectures. AKA, they'll put in extra barriers than possibly needed just in case
> > or because trying to figure every case is far too complicated. So when in doubt, use a barrier.
>
> Not... really. I mean, in practice sometimes, but that should not really happen.
>
> In core code (core kernel/compiler/library) doing that indicates that you do not understand what
> the data races are, and therefore your code is probably buggy *anyway*. Even if you hit it with
> a big barrier, there could easily be another race or synchronization bug lurking somewhere.
Well then, by all means, please start submitting patches to improve the performance of the Linux kernel in weakly ordered architectures by removing the unnecessary barriers.
I'm pretty sure IBM would like it.
But before you go all gung ho on how the Linux kernel design sucks, you might want to remind yourself that Linux successfully runs the larger cache-coherent systems ever made, with ~10x more logical CPUs than any other OS.
> Aaron Spink (aaronspink.delete@this.notearthlink.net) on August 17, 2014 12:42 am wrote:
>
> The point is that there is no minefield in going the *other* way. Maybe they create
> a minefield if they ever want to switch back, but if it is unquestioningly better
> to go with stronger ordering, then they have no barrier to make the transition.
Will make existing code/binaries run slower.
> > IIRC, Linus has commented on this topic in the past on this very board. They tend to be more conservative
> > with weakly ordered architectures. AKA, they'll put in extra barriers than possibly needed just in case
> > or because trying to figure every case is far too complicated. So when in doubt, use a barrier.
>
> Not... really. I mean, in practice sometimes, but that should not really happen.
>
> In core code (core kernel/compiler/library) doing that indicates that you do not understand what
> the data races are, and therefore your code is probably buggy *anyway*. Even if you hit it with
> a big barrier, there could easily be another race or synchronization bug lurking somewhere.
Well then, by all means, please start submitting patches to improve the performance of the Linux kernel in weakly ordered architectures by removing the unnecessary barriers.
I'm pretty sure IBM would like it.
But before you go all gung ho on how the Linux kernel design sucks, you might want to remind yourself that Linux successfully runs the larger cache-coherent systems ever made, with ~10x more logical CPUs than any other OS.