Hi Nathanaël,
Looking at the trace it doesn't appear as enough time has gone by at the end to fulfill a cache miss. That the last event? Could you provide me with some more of the trace if it's not? Thanks, Ali On 11.06.2012 10:52, Nathanaël Prémillieu wrote: > The benchmark is 445.gobmk with the score2 input. On my version of the > benchmarks, the run start after 200 900 000 000 of instructions. I run > the simulator in SE mode. The simulator loops repeating the few lines I > have copied. I join the whole trace output I have (around the point > where the simulator start to loop). > > I have posted the patch here: http://reviews.gem5.org/r/1268/Nathanaël > > Le 11/06/2012 15:21, Ali Saidi a écrit : > >> Hi Nathanaël, What SPEC2k6 benchmark are you running when the simulator doesn't finish? Are you running in SE or FS mode? Does it just hang at this point without events being processed or does it loop seemingly failing to complete this load? I would guess that your patch just exposes another bug, and it's not an issue with the patch. Would it be possible for you to post your patch on our review board (http://reviews.gem5.org [5])? If I can duplicate the issue, I might be able to help debug the issue more. Thanks, Ali On Jun 11, 2012, at 8:55 AM, Nathanaël Prémillieu wrote: >> >>> Hi, I have made some changes to the code: I have added a new flag (named pushRAS) in the PredictorHistory structure. This flag tracks whether the RAS has been pushed or not during a prediction. Then, in the squash function it is used to pop the RAS if necessary. I have made tests on a part of Spec2006 compiled for ARM. In most of the cases, there is less RAS misprediction with this modification. However, I have one case where the simulator is not able to finish the simulation. Here is a part of the trace output (debug-flags=All,-Event): 112977432760000: system.cpu.icache-mem_side_port-MemSidePort: Queue system.cpu.icache-mem_side_port-MemSidePort received retry 112977432760000: system.tol2bus: recvTimingReq: src system.tol2bus-p0 ReadReq 0x4f000 112977432760000: system.switch_cpus_1.iew.lsq: received pkt for addr:0x4f000 ReadReq 112977432760000: system.l2-cpu_side_port: Scheduling a retry while blocked 112977432760000: system.tol2bus: recvTimingReq: src system.tol2bus-p0 ReadReq 0x4f000 RETRY 112977432760000: system.tol2bus: The bus is now occupied from tick 112977432760000 to 112977432761000 112977432760000: system.cpu.icache-mem_side_port-MemSidePort: now waiting on a retry 112977432761000: system.cpu.icache-mem_side_port-MemSidePort: Queue system.cpu.icache-mem_side_port-MemSidePort received retry 112977432761000: system.tol2bus: recvTimingReq: src system.tol2bus-p0 ReadReq 0x4f000 112977432761000: system.switch_cpus_1.iew.lsq: received pkt for addr:0x4f000 ReadReq 112977432761000: system.l2-cpu_side_port: Scheduling a retry while blocked 112977432761000: system.tol2bus: recvTimingReq: src system.tol2bus-p0 ReadReq 0x4f000 RETRY ... I don't know if this happens because of my modifications (even if I don't how it can be related) or because I have stumble upon some bugs. Nathanaël Le 22/05/2012 04:56, Ali Saidi a écrit : >>> >>>> Hi Nathanaël, It's quite possible there is a bug. Unfortunately, I don't think anyone knows the branch predictor code extremely well. Please see inline. On May 21, 2012, at 3:36 PM, Nathanaël Prémillieu wrote: >>>> >>>>> Hi all, I'am currently looking at the branch prediction code. In the predict function (src/cpu/o3/bpred_unit_impl.hh: 160), if the BTB entry is not valid for a taken prediction, the prediction pred_taken is changed to false and the history is changed. Moreover, the RAS is popped if it is a call (l.254). But the RAS is popped only if the call is conditional (I don't know exactly why). If it is an unconditional call, the RAS is not popped. >>>> I think the reason that the code is like this is that you're definitely branching in this case. If you don't Because in this case you're definitely branching. In the case of not having a target fetch will be re-directed to the target when the branch resolves, so there will never be another opportunity to put the branch into the return address stack. However, I would assume that the conditional branch would have the same issue, so this seems to be a problem. >>>> >>>>> And if this unconditional call need to be squashed (by the squash function l.298), the RAS needs to be popped. For this instruction, the validBTB flag is not set, so the line 316 of the squash function is not executed ans thus, the entry is not popped. >>>> That seems to be an issue too. >>> _______________________________________________ gem5-users mailing list gem5-users@gem5.org [3] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [4] >> _______________________________________________ gem5-users mailing list gem5-users@gem5.org [6] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [7] Links: ------ [1] mailto:gem5-users@gem5.org [2] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [3] mailto:gem5-users@gem5.org [4] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [5] http://reviews.gem5.org [6] mailto:gem5-users@gem5.org [7] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
