Hello, This is a good question for which I don't have a simple answer. I think we would need more context in the access stream/debug trace. I also suggest digging into the code to see what happens when the line "Single request, going to a busy rank" is printed. The code around that DPRINTF will probably have some hints.
Cheers, Jason On Fri, Jun 5, 2020 at 12:08 AM yangyuqing--- via gem5-users < [email protected]> wrote: > I'm using HMC as my memory in my system. And I found a problem that once a > simobject sent a read request, the latency of the response was different. I > print out the DRAM trace. > 1. if a read request is processed by dramctrl as follow, the latency is > longer. > 377334000: system.hmc_dev.mem_ctrls00: recvTimingReq: request PIMRead addr > 1775248 size 8 > 377334000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size > 0, entries needed 1 > 377334000: system.hmc_dev.mem_ctrls00: Address: 1775248 Rank 0 Bank 0 Row > 3467 > 377334000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size > 0, entries needed 1 > 377334000: system.hmc_dev.mem_ctrls00: Adding to read queue > 377334000: system.hmc_dev.mem_ctrls00: Request scheduled immediately > 377334000: system.hmc_dev.mem_ctrls00: QoS Turnarounds selected state READ > 377334000: system.hmc_dev.mem_ctrls00: Single request, going to a busy rank > 377334000: system.hmc_dev.mem_ctrls00: No Reads Found - exiting > 2.if a read request is processed by dramctrl as follow, the latency is > shorter. > 344235000: system.hmc_dev.mem_ctrls00: recvTimingReq: request PIMRead addr > 1774464 size 8 > 344235000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size > 0, entries needed 1 > 344235000: system.hmc_dev.mem_ctrls00: Address: 1774464 Rank 0 Bank 0 Row > 3465 > 344235000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size > 0, entries needed 1 > 344235000: system.hmc_dev.mem_ctrls00: Adding to read queue > 344235000: system.hmc_dev.mem_ctrls00: Request scheduled immediately > 344235000: system.hmc_dev.mem_ctrls00: QoS Turnarounds selected state READ > 344235000: system.hmc_dev.mem_ctrls00: Single request, going to a free rank > 344235000: system.hmc_dev.mem_ctrls00: Timing access to addr 1774464, > rank/bank/row 0 0 3465 > 344235000: system.hmc_dev.mem_ctrls00: Activate at tick 344241000 > 344235000: system.hmc_dev.mem_ctrls00: Activate bank 0, rank 0 at tick > 344241000, now got 1 active > 344235000: system.hmc_dev.mem_ctrls00: Access to 1774464, ready at > 344264300 next burst at 344254400. > 344235000: system.hmc_dev.mem_ctrls00: Precharging bank 0, rank 0 at tick > 344262600, now got 0 active > 344235000: system.hmc_dev.mem_ctrls00: Auto-precharged bank: 0 > > I think the point is Single request, going to a free or busy rank. I want > to know in which case the rank is busy and why latency is different. > _______________________________________________ > gem5-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >
_______________________________________________ gem5-users mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
