Hi Nilay, To me it reads like there is a now a known issue with the MinorCPU, and an intentional disparity between the O3CPU and MinorCPU. If the split request snoop is really a problem the change should be made to both the CPU models at once imho.
Andreas From: Nilay Vaish <[email protected]<mailto:[email protected]>> on behalf of Nilay Vaish <[email protected]<mailto:[email protected]>> Reply-To: Nilay Vaish <[email protected]<mailto:[email protected]>> Date: Tuesday, 15 September 2015 14:57 To: Nilay Vaish <[email protected]<mailto:[email protected]>>, Default <[email protected]<mailto:[email protected]>>, Andreas Hansson <[email protected]<mailto:[email protected]>>, Hongil Yoon <[email protected]<mailto:[email protected]>> Subject: Re: Review Request 2975: cpu, o3: consider split requests for LSQ checksnoop operations This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2975/ On July 16th, 2015, 9:55 p.m. UTC, Andreas Hansson wrote: Could you elaborate on when this is a problem? Why is this only affecting o3? On July 17th, 2015, 5:17 p.m. UTC, Hongil Yoon wrote: This may affect other CPU models (e.g. minor). I am not familiar with it, so I need to read codes. On July 27th, 2015, 1:30 p.m. UTC, Andreas Hansson wrote: What ever test case you used for the o3, could you run it on the other CPUs as well? Thanks On July 27th, 2015, 8:27 p.m. UTC, Hongil Yoon wrote: I will check whether the other CPUs, e.g., minor cpu, are affected by this issue. On August 4th, 2015, 2:46 a.m. UTC, Hongil Yoon wrote: I think that the concern boils down to whether snoop operations are needed for the load-store queues (LSQ) of a CPU model. If so, this issue will affect the CPU model. The snoop operation has not been implemented for the Minor CPU. However, I think that it is required for invalidation requests from private caches. That is, the load queue needs to be searched for any matching in-flight loads that were (being) executed but haven't been committed yet. In this process, split requests need to be considered as well. I couldn't read all the codes carefully, but this is my understanding so far. Andreas, Hongil wrote over a month back that MinorCPU might be affected. Those using MinorCPU regularly should be able to decide better whether changes are actually required or not. If you want to ensure parity between between LSQ for the two cpus, I would rather have them either be objects of the same class or make them inherit from some base class. - Nilay On July 17th, 2015, 10:13 p.m. UTC, Hongil Yoon wrote: Review request for Default. By Hongil Yoon. Updated July 17, 2015, 10:13 p.m. Repository: gem5 Description Changeset 10917:331f426b24a7 --------------------------- cpu, o3: consider split requests for LSQ checksnoop operations This patch enables instructions in LSQ to track two physical addresses for corresponding two split requests. Later, the information is used in checksnoop() to search for/invalidate the corresponding LD instructions. The current implementation has kept track of only the physical address that is referenced by the first split request. Thus, for checksnoop(), the line accessed by the second request has not been considered, causing potential correctness issues. Testing booting o3 with the classic-memory model was done without any issues (single core, x86). Diffs * src/cpu/base_dyn_inst.hh (5c76426fd9ee) * src/cpu/base_dyn_inst_impl.hh (5c76426fd9ee) * src/cpu/o3/iew_impl.hh (5c76426fd9ee) * src/cpu/o3/lsq_unit_impl.hh (5c76426fd9ee) View Diff<http://reviews.gem5.org/r/2975/diff/> -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
