3 ms·
> I'm guessing what you mean is for the TLB to get a notification when the physical memory that contains the page mapping it was loaded from is changed. Yes, t
by brandmeyer 6y ago
> I'm guessing what you mean is for the TLB to get a notification when the physical memory that contains the page mapping it was loaded from is changed.
Yes, that's right.
Let us conceive of an inclusive cache architecture, just for the sake of argument. L2 already maintains a directory listing of all the lines which are present in L1I and L1D, and forwards cache coherency traffic to those caches based on the messages it receives. Expanding this to the ITLB and DTLB would be exactly the same circuits. The hard parts are already done.
But I think you're onto something with the hardware-managed dirty bit. Its much less general than the S->E->M transition, and doesn't need the Exclusive state at all.
I've done a bit more digging in the background. Turns out that ARMv8's TLB invalidate instructions are broadcasted operations. You don't need IPIs to execute them on every core. So processors do have some snoopy and/or directory management hardware interface for managing TLB shootdown. It just isn't as general-purpose as the rest of the cache maintenance hardware.
- eqvinox 6y agoA separate broadcast makes much more sense on the complexity front... if it were tied to the cache, the TLB wouldn't really care about anything other than specific transitions. It doesn't need the cacheline contents, and one cacheline would generally hold 8 or 16 PTEs (depending on PTE and cacheline size.) You'd also necessarily be binding to the PTE's physical address since page table walks occur on physical addresses. With a broadcast, on the other hand, you get the specific transition event you need, and you can choose whether to broadcast the physical PTE, physical data or virtual (+ASID) address, or both. You can also have an acknowledgement returned if needed.