Thanks for the head up Nilay. I'm not sure how to check if it is valid or not, so I just printed out all tlb entry information and compared it.
4949688231000: system.cpu.dtb: tlb2[39] entry : VPN : 0x7fab3f32c000, PPN : 0x1facd000, logBytes : 12, writable : 0, user : 1, uncacheable : 0, global : 0, patBit : 1, noExec : 0, lruseq : 14322 4949688231000: system.cpu.dtb: tlb2[40] entry : VPN : 0x7fab3f32c000, PPN : 0x1facd000, logBytes : 12, writable : 1, user : 1, uncacheable : 0, global : 0, patBit : 1, noExec : 0, lruseq : 14566 As you can see they have same translation but different bits in wirtalbe and lruseq. Is there any other way to check if the entry is vaild in trie and tlb? On Mon, Jan 7, 2013 at 8:15 PM, Nilay Vaish <ni...@cs.wisc.edu> wrote: > On Mon, 7 Jan 2013, Jinchun Kim wrote: > > It's X86 FS and classic model. >> >> Jinchun Kim >> >> On Jan 7, 2013, at 4:17 PM, Nilay Vaish <ni...@cs.wisc.edu> wrote: >> >> On Mon, 7 Jan 2013, Jinchun Kim wrote: >>> >>> I was printing out TLB entries whenever virtual address hit or miss on >>>> TLB. >>>> And I found that TLB miss occurs even though TLB already has matched >>>> entry >>>> in it. >>>> >>>> For example, >>>> 4949665272500: system.cpu.dtb: L1 TLB Miss : VA = 0x7fab3f32c280 >>>> 4949665272500: system.cpu.dtb: tlb[41] : VPN = 0x7fab3f32c000, PPN = >>>> 0x1facd000 >>>> >>>> Translation for VA = 0x7fab3f32c280 is already in tlb[41]. >>>> However, it is considered as miss. >>>> After this weird TLB miss, gem5 puts same translation in TLB again. >>>> >>>> > Are you sure that this entry that you printed is valid? > > -- > Nilay > -- *Jinchun Kim*
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
