[libre-riscv-dev] TLB Replacement Policy

[Jacob Lifshay]

What I was thinking of is that the software handling a TLB miss would
choose what entry to replace in the L2 TLB. For the L1, you could pick
random or LRU. You could use a lfsr for the random number generator. we
would need a way to save and restore the lfsr state to avoid side-channels
for security. for a 8-16 entry L1, an 8-bit lfsr is probably good enough.

Using lru requires more hw to keep track, so random may be better.

On Sat, Feb 16, 2019, 14:41 Daniel Benusovich <flyingmonkeys1996 at gmail.com>
wrote:

> I have pushed the beginnings of a CAM and its entries.
>
> Most of the data is straight forward with exception of writes.
>
> I am only talking about the CAM here not the TLB as a whole!
>
> When the CAM is writing it operates much like a fully associative cache
> where every entry is checked. If an entry is found with for the key we want
> to write should we overwrite whatever is in that table? The key can be
> whatever we want it to be either just the tag of the VMA, or the
> combination of the VMA and the ASID. I believe the second option is better
> for the CAM functionality as I understand it. However, if we want to keep
> the ASID  to be seperate from the key we will have collisions on tags from
> different ASIDs. In that case would we want the CAM to return multiple
> entries which we go through later and doesn't this defeat the purpose of
> the single cycle lookup?
>
> Secondly, in the event that the CAM is filled up and no collisions
> occurred a replacement is needed. We should use a LRU (as is expected)
> algorithm but I am unfamiliar with any hardware based algorithms that will
> quickly allow for keeping track of a generic sized CAM in any efficient
> manner. Do you guys have any suggestions as to where to look for this or
> implementations? I am more than happy to code up what I think would work
> but I promise it would be about as fast as the Great Molasses Flood of 1919.
>
> Happy Saturday!
>
> Daniel B.
>