> On oct. 21, 2016, 1:29 après-midi, Pierre-Yves Péneau wrote: > > Hi, > > > > Someone can commit this patch ? I don't have right access on the > > repository, either Sophiane. > > Thank you. > > Jason Lowe-Power wrote: > Sorry we've been so slow on this patch. A couple of questions before I > commit. > > 1. Are all of Andreas H.'s comments resolved? I'd like to see a "Ship It" > from him. > 2. You need to make sure the regressions are passing. I understand that > our regression testing is poor, but I know that the learning_gem5 regression > is failing because of this patch. The file > configs/learning_gem5/part1/caches.py needs to be updated. There are likely > other files that need to be updated as well (configs/examples/arm/devices.py > comes to mind, there may be others). > > Pierre-Yves Péneau wrote: > 1. Sophiane answered to Andreas H.' issues but I did not respond (quote: > "Please go ahead with the patch as is"). I assume it's ok even without a > "Ship It" from him. > 2. Regression tests have been done. Failures are due to missing CPU2000 > benchmarks. The review will be update soon.
The regression tests passed, except the ones that require proprietary binaries. - Sophiane ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8960 ----------------------------------------------------------- On oct. 24, 2016, 2:56 après-midi, Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated oct. 24, 2016, 2:56 après-midi) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11688:9dba209f1590 > --------------------------- > mem: Split the hit_latency into tag_latency and data_latency > > If the cache access mode is parallel, i.e. "sequential_access" parameter > is set to "False", tags and data are accessed in parallel. Therefore, > the hit_latency is the maximum latency between tag_latency and > data_latency. On the other hand, if the cache access mode is > sequential, i.e. "sequential_access" parameter is set to "True", > tags and data are accessed sequentially. Therefore, the hit_latency > is the sum of tag_latency plus data_latency. > > > Diffs > ----- > > src/mem/cache/tags/base.cc 4aac82f10951 > src/mem/cache/tags/base_set_assoc.hh 4aac82f10951 > src/mem/cache/tags/fa_lru.cc 4aac82f10951 > configs/common/Caches.py 4aac82f10951 > configs/common/O3_ARM_v7a.py 4aac82f10951 > configs/example/arm/devices.py 4aac82f10951 > configs/learning_gem5/part1/caches.py 4aac82f10951 > src/mem/cache/Cache.py 4aac82f10951 > src/mem/cache/base.hh 4aac82f10951 > src/mem/cache/base.cc 4aac82f10951 > src/mem/cache/tags/Tags.py 4aac82f10951 > src/mem/cache/tags/base.hh 4aac82f10951 > > Diff: http://reviews.gem5.org/r/3502/diff/ > > > Testing > ------- > > Tested using --Debug-flags=Cache > > > Thanks, > > Sophiane SENNI > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
