It might be obvious and I guess that's what you are doing already but I forgot to mention that another solution ofc would be to revert the patches that add support for the prefetch exclusive instruction.
Nikos On 29/03/2019 11:26, Nikos Nikoleris wrote: > Hi William, > > This is indeed a bug which is due to the change that implement the > prefetch exclusive instruction. > > The classic memory system in gem5 was designed with two assumptions > which are relevant here: > > * A cache which fetches a block with an intention to modify it is > expected to become the point of ordering and therefore commits to > respond to any snoop requests [1]. > * A cache that fetches an exclusive copy of the block, does so with the > intention to modify it [2]. Immediately after it receives the block, it > will mark it as dirty and it will become the point of ordering. As the > point of ordering it responds to any pending snoops. > > Unfortunately, the prefetch exclusive request breaks the second > assumption, it fetches an exclusive block without a clear intention to > modify it. In cases where the block is not modified, it won't be marked > as a dirty and the cache doesn't become the point of ordering although > it has committed to respond to pending snoops. This is the reason for > the deadlock. There are snoops that are stuck waiting for responses. > > One simple solution [3] is to force the prefetch exclusive request to > unconditionally mark the block dirty. This should work as it doesn't > break any of the assumptions *but* it might mark blocks as dirty even > though they are not. As a result it might increase writebacks. In > practice this shouldn't be a big problem unless the application is > unnecessarily using prefetch exclusive instructions. > > Another solution is to change the design of the memory system to handle > this properly, I've been thinking about it and it's not that > straightforward. > > [1]: When a cache commits to respond, it "informs" the xbar/PoC (point > of coherence) and the other caches of its intention to respond. As a > result the request will not be send to the main memory. > [2]: In fact the assumption is that in the needsWritable MSHR there is > at least one WriteReq before any snoops from other caches. > [3]: https://gem5-review.googlesource.com/c/public/gem5/+/17729 > > Hope this helps. > > Nikos > > On 29/03/2019 10:33, Simon William wrote: >> Hello all, >> >> I have been using gem5 for about 2 years now, and have run into a >> problem that I cannot seem to surmount, though I have located the root >> cause. I have been using workload automation to mount a local folder >> from host into my gem5 fs simulation, allowing me to modify and cross >> compile applications on the host and then run them easily in gem5. To do >> this, I followed the instructions on >> http://gem5.org/WA-gem5#Using_gem5_with_Workload_Automation, and run the >> command >> >> mount -t 9p -n gem5 /mnt >> -oaname=/home/wsimon/temp,version=9p2000.L,uname=root,access=user >> >> To mount 9p filesystem within gem5. This has worked very well up until >> recently updating the the newest version of gem5. Now, while mounting >> still works in the O3 CPU, I get a simulation timout in the Minor CPU: >> >> Exiting @ tick 18446744073709551615 because simulate() limit reached >> >> diod: caught SIGTERM: shutting down >> >> info: Trying to kill diod with SIGKILL as SIGTERM failed >> >> I tracked down the cause of this error to git commit >> *59e3585a84ef172eba57c9936680c0248f9a97db >> <https://github.com/gem5/gem5/commit/59e3585a84ef172eba57c9936680c0248f9a97db#diff-e43d16de0f4ee528cd758d7ae8513ed8>*, >> in which Prefetching for stores is added to the ARM ISA (I am using >> aarch64 ISA), specifically the 4 lines in >> *src/arch/arm/isa/insts/ldr64.isa*. >> >> LoadImm64("prfm", "PRFM64_IMM", 8, flavor="mprefetch").emit() >> >> LoadReg64("prfm", "PRFM64_REG", 8, flavor="mprefetch").emit() >> >> LoadLit64("prfm", "PRFM64_LIT", 8, literal=True, >> >> flavor="mprefetch").emit() >> >> LoadImm64("prfum", "PRFUM64_IMM", 8, flavor="mprefetch").emit() >> >> The “mprefetch” flavor modifies the memFlags in the following way (also >> in src/arch/arm/isa/insts/ldr64.isa): >> >> if self.flavor == "dprefetch": >> >> self.memFlags.append("Request::PREFETCH") >> >> self.instFlags = ['IsDataPrefetch'] >> >> elif self.flavor == "iprefetch": >> >> self.memFlags.append("Request::PREFETCH") >> >> self.instFlags = ['IsInstPrefetch'] >> >> * elif self.flavor == "mprefetch":* >> >> * self.memFlags.append("((((dest>>3)&3)==2)? \* >> >> * (Request::PF_EXCLUSIVE):(Request::PREFETCH))")* >> >> * self.instFlags = ['IsDataPrefetch']* >> >> if self.micro: >> >> self.instFlags.append("IsMicroop") >> >> If I modify the emit commands above to emit with the flavor “dprefetch”, >> as was previously the case, I have no problems, so the timeout error >> must arise from a memory request being tagged as PF_EXCLUSIVE instead of >> PREFETCH. >> >> If I understand correctly, the PF_EXCLUSIVE tag requests that a memory >> location be prefetched and marked as exclusive, to allow storing. I’m >> not sure why this would cause a hang in the code. Can anyone shed >> further light on the possible cause of this? >> >> Sincerely, >> >> William >> > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
