From: user5857@newsgrouper.org.invalid
Robert Finch posted:
> Background TLB flushing via HW state machine?
Because My 66000 MMU is defined as coherent, there is no flushing
of the TLB. A write that damages TLB state will invalidate the
entry all by itself.
> I am not sure about the
> merits of this approach. Because the TLB is implemented using BRAM the
> valid bits are not individually accessible. The design is too low cost
> to support a separate valid bit array. Therefore, to flush the entire
> TLB there is a background process *1 that reads the TLB entries, clears
> the valid bit then writes it back to the TLB.
>
> *1 a couple of states in the page walking state machine.
>
> The automatic flushing for the entire TLB in HW allows translations to
> continue to take place while the background HW process runs. If the
> entire TLB needs to be flushed, a master TLB count is incremented. TLB
> entries are considered valid only if the entry count matches the master
> TLB count. The background process invalidates TLB entries where the
> entry count does not match the TLB count.
>
> As long as the background process can cycle through (on average) all the
> TLB entries before the TLB is flushed again there should be no issues
> with stale translations. The master TLB count is a six-bit counter. The
> flush cycle rate can be controlled. Setting the rate to zero disables
> automatic flushes. Setting it to all ones flushes at the maximum rate,
> effectively disabling translations while the flush takes place.
>
> It may be an option to not automatically flush global translations.
>
> Read up on the TLB in the Linux docs. It seems the TLB may be entirely
> flushed or flushed page by page. Thinking about doing the page-by-page
> flush as background HW process. Flush all the entries matching an ASID.
>
>
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
