By: anon (anon.delete@this.anon.com), August 17, 2014 7:53 am
Room: Moderated Discussions
Ricardo B (ricardo.b.delete@this.xxxxx.xx) on August 17, 2014 6:43 am wrote:
> 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.
Perhaps not if some barriers can be turned into noops.
>
> > > 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.
I have done, for what it's worth (which isn't much seeing that I'm an anonymous internet lurker, but same goes for ad hominem attacks).
> But before you go all gung ho on how the Linux kernel design sucks,
I never have. Many aspects of it have required improvement over the years, and familiarity breeds contempt.. no, not really, but you can obviously see deficiencies the more you know the code. It's the same as anything really.
> 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.
That does not have much to do memory consistency handling in driver APIs, however.
> 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.
Perhaps not if some barriers can be turned into noops.
>
> > > 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.
I have done, for what it's worth (which isn't much seeing that I'm an anonymous internet lurker, but same goes for ad hominem attacks).
> But before you go all gung ho on how the Linux kernel design sucks,
I never have. Many aspects of it have required improvement over the years, and familiarity breeds contempt.. no, not really, but you can obviously see deficiencies the more you know the code. It's the same as anything really.
> 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.
That does not have much to do memory consistency handling in driver APIs, however.
