> On July 16, 2015, 9:55 p.m., Andreas Hansson wrote: > > Could you elaborate on when this is a problem? Why is this only affecting > > o3? > > Hongil Yoon wrote: > This may affect other CPU models (e.g. minor). I am not familiar with it, > so I need to read codes. > > Andreas Hansson wrote: > What ever test case you used for the o3, could you run it on the other > CPUs as well? Thanks > > Hongil Yoon wrote: > I will check whether the other CPUs, e.g., minor cpu, are affected by > this issue. > > 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 ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2975/#review6780 ----------------------------------------------------------- On July 17, 2015, 10:13 p.m., Hongil Yoon wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2975/ > ----------------------------------------------------------- > > (Updated July 17, 2015, 10:13 p.m.) > > > Review request for Default. > > > 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. > > > 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 > > Diff: http://reviews.gem5.org/r/2975/diff/ > > > Testing > ------- > > booting o3 with the classic-memory model was done without any issues (single > core, x86). > > > Thanks, > > Hongil Yoon > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
