> 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.
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. - Hongil ----------------------------------------------------------- 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
