Michael S (already5chosen.delete@this.yahoo.com) on August 19, 2018 2:46 pm wrote:
> Travis (travis.downs.delete@this.gmail.com) on August 19, 2018 2:32 pm wrote:
> > matthew (nobody.delete@this.example.com) on August 19, 2018 12:51 pm wrote:
> > > I think there's a good counter-example to your point, which is the Itanium McKinley implementation
> > > of fetchadd. If the line is in L1, the CPU does it. If it's not, the core tells the
> > > L2 to do it. Obviously no-one's citing Itanium as a good example of much these days,
> > > but I never heard anyone complain about its implementation of atomics.
> >
> > As far as I can tell McKinley only ever had 1 core, right? So was this some kind
> > of optimization for multiple socket machines? The line still had to get back to
> > the core, since this is fetch and add, so you always suffer L2 latency?
> >
> > Here the L2 is still private so it's kind of still a local operation. I guess the idea
> > maybe is that atomic operations are a signal that a line might be probed by another
> > socket so leaving the current value in the L2 reduces latency if that happens.
> >
>
> Value would be in L2 anyway. Remember, L1D is write through .

Oh right I was thinking of write-back L1D.

I guess the lines are all kind of blurry when talking about a private write-through L1D and private L2. Every mutating operation, atomic or not is going to the L2 more or less immediately and the primary difference between the two are the atomicity concerns. In this case you either need to implement some speculative logic in the core to attempt the atomic operations against L1, or you push them down to L2 where they have to go anyways which can do the operation in one shot.

This makes sense and it seems like the operation is no more expensive for having done it in L2 (since you'd need to coordinate with L2 somehow anyways).

This is very different than pushing the atomic operation down all the way to the shared domain, which in Itanium was memory, I guess? It seems even L3 was CPU-private in Itanium.