The gem5 Users mailing list

View all threads

EmulationPageTable Cycles to redo translation failures - How to avoid/Control TLB Failures?

Abdlerhman Abotaleb
Fri, Jul 8, 2022 11:24 PM

P {margin-top:0;margin-bottom:0;} Hi All

I'm trying to understand how the emulated page table works in GEM5. I'm using 03 CPU model.

  1. How to control number of cycles needed to redo TLB translation again if it fails?

Is there any schedule for any of the following translation events:

i.e. EmulationPageTable::translate

or any of the following functions that call it in sequence:

LSQ::SingleDataRequest::initiateTranslation ->

LSQ::LSQRequest::sendFragmentToTranslation ->

BaseMMU::translateTiming -> TLB::translateTiming -> TLB::translate -> EmulationPageTable::translate


Fetch::fetchCacheLine(Addr vaddr, ThreadID tid, Addr pc) -> BaseMMU::translateTiming

I can observe for example, sequence of 32 trials to translate a virtual address ,when start to execute the corresponding load instruction.

Here the load instruction under concern start to execute:

Start of the trials to do translations at tick 201904728

And finally, after another 31 failed trials, translation is done sucessfully at tick 203372151 !!

  1. Why do TLB translation fail in the emulated page table?

Can I make an emulated buffer large to avoid/reduce such emulated TLB misses?

  1. How many pending faulty translations to addresses within the same page, can be issued once a successful translation done to any of the pending addresses?

for example, loading bytes from the following addresses : 0x423210 , 0x423410 , 0x423610 , 0x423810 , 0x423a10 , 0x423c10 , 0x423e10) They are all in the same VPN(0x423). They suffer, for a while, from failure to do translation.

Then once TLB translation is done for the first address , only , 0x415410 , 0x415610 , 0x415810 translates immediately , but other four requests need additional cycles as shown in the following table . Why?