sr (nobody.delete@this.nowhere.com) on September 11, 2021 1:29 am wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on September 9, 2021 2:46 am wrote:
>
> > 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.
>
>
>
> Aliasing isn't problem. There's no way but deny aliasing in cache-coherent system. Easiest and
> most logical way to implement is multi-level cache where core is reading from L1 cache vith virtual
> tags and L2 is doing cache filling and evicting with physical tags. That means that L1 cache
> lines need to have both virtual and physical tags but that isn't any kind of problem.
>
> With you approach to allow aliasing copies in L1 will result no memory coherence.

Aliasing is a problem, especially with process ids. The same physical address may be mapped to different addresses in different processes. It is very desirable to not do any special work going from one process to another except o prefix the process id to the virtual address. L1 does not really need physical addresses with what I was talking about though at least an index from L1 into L2 and a backward one from L2 to L1 are desirable and there wouldn't be any aliasing in L1 because any previous alias will be evicted or moved to the new slot.