Hello, Memory accesses that miss the caches and TLB may take a very long time to commit. Depending on your configurations (CPU clock/mem latency) what you're seeing may happen.
Regards, -- Fernando A. Endo, PhD student and researcher Université de Grenoble, UJF France 2015-04-03 18:50 GMT+02:00 Daniel Byrne <[email protected]>: > Hello, > > I am using the O3CPU in syscall emulation mode. I have a few instructions > that end up taking many cycles for memory access. Here is debugged output > of the first instruction that takes a long time: > > 210220000: global: DynInst: [sn:394019] Instruction created. Instcount for > system.cpu = 71 > 210220000: system.cpu.fetch: [tid:0]: Instruction PC 0x120016604 (0) > created [sn:394019]. > 210220000: system.cpu.fetch: [tid:0]: Instruction PC 0x120016604 (0) > created [sn:394019]. > 210220000: system.cpu.fetch: [tid:0][sn:394019]: Sending instruction to > decode from fetch queue. Fetch queue size: 3. > 210220500: system.cpu.decode: [tid:0]: Processing instruction [sn:394019] > with PC (0x120016604=>0x120016608) > 210220500: system.cpu.decode: [tid:0]: Processing instruction [sn:394019] > with PC (0x120016604=>0x120016608) > 210221000: system.cpu.rename: [tid:0]: Processing instruction [sn:394019] > with PC (0x120016604=>0x120016608). > 210221000: global: [sn:394019] has 1 ready out of 1 sources. RTI 0) > 210221000: system.cpu.rename: [tid:0]: Adding instruction to history > buffer (size=34), [sn:394019]. > 210221500: system.cpu.commit: Inserting PC (0x120016604=>0x120016608) > [sn:394019] [tid:0] into ROB. > 210222000: system.cpu.iew: [tid:0]: Issue: Adding PC > (0x120016604=>0x120016608) [sn:394019] [tid:0] to IQ. > 210222000: system.cpu.iew: [tid:0]: Issue: Adding PC > (0x120016604=>0x120016608) [sn:394019] [tid:0] to IQ. > 210222000: system.cpu.iew.lsq.thread0: Inserting load PC > (0x120016604=>0x120016608), idx:8 [sn:394019] > 210222000: system.cpu.iew.lsq.thread0: Inserting load PC > (0x120016604=>0x120016608), idx:8 [sn:394019] > 210222000: system.cpu.iq: Adding instruction [sn:394019] PC > (0x120016604=>0x120016608) to the IQ. > 210222000: system.cpu.memDep0: No dependency for inst PC > (0x120016604=>0x120016608) [sn:394019]. > 210222000: system.cpu.memDep0: Adding instruction [sn:394019] to the ready > list. > 210222000: system.cpu.iq: Instruction is ready to issue, putting it onto > the ready list, PC (0x120016604=>0x120016608) opclass:30 [sn:394019]. > 210222000: system.cpu.iq: Thread 0: Issuing instruction PC > (0x120016604=>0x120016608) [sn:394019] > 210222000: system.cpu.memDep0: Issuing instruction PC 0x120016604 > [sn:394019]. > 210222500: system.cpu.iew: Execute: Processing PC > (0x120016604=>0x120016608), [tid:0] [sn:394019]. > 210222500: system.cpu.iew: Execute: Processing PC > (0x120016604=>0x120016608), [tid:0] [sn:394019]. > 210222500: system.cpu.iew.lsq.thread0: Executing load PC > (0x120016604=>0x120016608), [sn:394019] > 210222500: system.cpu.iew.lsq.thread0: Doing memory access for inst > [sn:394019] PC (0x120016604=>0x120016608) > 210230000: system.cpu.commit: [tid:0]: Can't commit, Instruction > [sn:394019] PC (0x120016604=>0x120016608) is head of ROB and not ready > ...(932 cycles) > 210696000: system.cpu.commit: [tid:0]: Can't commit, Instruction > [sn:394019] PC (0x120016604=>0x120016608) is head of ROB and not ready > 210696250: system.cpu.iew.lsq.thread0: Writeback event [sn:394019]. > 210696250: system.cpu.iew.lsq.thread0: Activity: Writeback event > [sn:394019]. > 210696500: system.cpu.iew: Sending instructions to commit, [sn:394019] PC > (0x120016604=>0x120016608). > 210696500: system.cpu.iew: Sending instructions to commit, [sn:394019] PC > (0x120016604=>0x120016608). > 210696500: system.cpu.iq: Completing mem instruction PC: > (0x120016604=>0x120016608) [sn:394019] > 210696500: system.cpu.memDep0: Completed mem instruction PC > (0x120016604=>0x120016608) [sn:394019]. > 210696500: system.cpu.commit: [tid:0]: Can't commit, Instruction > [sn:394019] PC (0x120016604=>0x120016608) is head of ROB and not ready > 210697000: system.cpu.commit: [tid:0]: Marking PC > (0x120016604=>0x120016608), [sn:394019] ready within ROB. > 210697000: system.cpu.commit: [tid:0]: Instruction [sn:394019] PC > (0x120016604=>0x120016608) is head of ROB and ready to commit > 210697500: system.cpu.commit: Trying to commit head instruction, > [sn:394019] [tid:0] > 210697500: system.cpu.commit: Committing instruction with [sn:394019] PC > (0x120016604=>0x120016608) > 210697500: system.cpu.commit: Committing instruction with [sn:394019] PC > (0x120016604=>0x120016608) > 210697500: system.cpu.rob: [tid:0]: Retiring head instruction, instruction > PC (0x120016604=>0x120016608), [sn:394019] > 210697500: system.cpu: Removing committed instruction [tid:0] PC > (0x120016604=>0x120016608) [sn:394019] > 210697500: system.cpu: Removing committed instruction [tid:0] PC > (0x120016604=>0x120016608) [sn:394019] > 210697500: system.cpu: Removing instruction, [tid:0] [sn:394019] PC > (0x120016604=>0x120016608) > 210698000: system.cpu.rename: [tid:0]: Freeing up older rename of reg 289, > [sn:394019]. > 210699000: global: DynInst: [sn:394019] Instruction destroyed. Instcount > for system.cpu = 69 > > I was wondering if there was a reason why it is taking so many cycles to > mark the PC ready? We are using default values in our options. Could this > be a bug? > > The only other evidence I could find of this happening came from a thread > 3 years ago on gem5-dev, but the issue has been fixed on x86. Is it > possible it was never fixed in ALPHA? > http://permalink.gmane.org/gmane.comp.emulators.m5.devel/12519 > > > > -- > Daniel Byrne > Computer Science > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
