dmcq (dmcq.delete@this.fano.co.uk) on September 9, 2021 2:46 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 8, 2021 12:34 pm wrote:
> > dmcq (dmcq.delete@this.fano.co.uk) on September 8, 2021 8:22 am wrote:
> > > sr (nobody.delete@this.nowhere.com) on September 8, 2021 5:49 am wrote:
> > > > So Power10 is using virtually tagged L1 for both instruction and
> > > > data caches and it does address translation only after L1-miss.
> > >
> > > I know the Linux people say the sky will fall if one does that and it
> > > would involve a bit of trickery but it's certainly what I'd go for.
> >
> > Oh, we don't care about implementation of the L1 caches, and they can use
> > whatever indexing and tags they want as long as they aren't stupid.
> >
> > So it's the historical pure virtually tagged caches that are bad, and that used to be
> > reasonably common. They don't exist any more (apart from possibly some broken toy core
> > used for educational purposes - mostly presumably as a "don't do this" education).
> >
> > People learnt their lesson.
> >
> > You can do entirely virtual L1 lookups if you just have all the pieces in place to avoid the bad semantics
> > that the traditional model had (ie no alias issues, proper
> > writeback, yadda yadda). And you can set up those
> > things at cache fill time, rather than at lookup time (although it is likely a combination of the two).
> >
> > The historical problems are about exposing aliases as lack of coherence, and the crazy performance
> > issues you had with direct-mapped or write-through caches. None of them are fundamental to virtual
> > indexing per se, they are just fundamental to overly simplistic and badly done virtual indexing.
> >
> > There is no way that POWER10 uses the traditional broken purely virtual cache model. It's
> > against the POWER cache coherency architectural guarantees. So they'll have the pieces in
> > place to make them act all coherent in hardware, are are multi-way associative etc etc.
> >
> > (And no, I have no inside knowledge, so the above is based
> > purely on "I seriously doubt some IBM CPU engineer
> > went on a crazy drug-induced architectural rampage and screwed up the latest implementation completely").
> >
> > The problem with the old-school virtual caches was that in order to
> > get cache coherence, you needed to jump through hoops in software.
> >
> > And hey, it's not like old-school physically indexed caches were great either. You can
> > most certainly screw that up too. Make it direct-mapped, and it's hot garbage regardless
> > of how many physical index bits you have, although it's slightly less painfully so.
> >
> > I don't really expect to ever see that kind of a train wreck again.
> >
> > Linus
>
> Yes agree with all that. And by trickery I didn't mean anything too amazing. The problem is to avoid having
> two copies of the same data in L1 because of aliasing. If the L2 cache holds an index into the L1 cache whenever
> data is copied into L1 then it shouldn't be to difficult to evict the old copy before putting in the new. It
> means the data goes ping pong in the L1 cache if one uses aliases at the same time. Probably one would use
> process id as well attached to the virtual address to avoid using the mechanism too much. With this one can
> abort the TLB lookup for L2 as soon as there is a hit in L1, it's never needed for the L1 lookup.

Though I'd still store the physical address from the translation in L1 to help with coherency as things could be popping in and out of L1, one can't be certain there aren't aliases in the pipeline even if they aren't in the cache. Unless of course you block the pipeline until the condition goes away which might also work.