> On Feb. 22, 2012, 6:02 p.m., Steve Reinhardt wrote: > > This looks fine, though it made me curious *why* atomic cpu has an extra > > port... looks like it's due to this 'fastmem' option: > > http://repo.gem5.org/gem5/rev/f1c856d8c460 > > > > I don't know of anyone who uses this, and I wonder just how much of a > > performance boost it provides anyway. I'm inclined to say we should just > > get rid of this option and the extra atomic cpu port so you can clean this > > up further. > > > > Thoughts, Ali? > > > > Ali Saidi wrote: > It's a 10-15% perf boost, which isn't bad. Perhaps we should default to > use it if you don't specify caches.
Maybe a stupid question, but is there ever any point in using caches with atomic CPU? There is no useful timing information coming out, so it might as well be as fast as possible. The only situation where I would see a use for not using the fast "bypass" to memory would be debugging o3/inorder by replacing it with atomic. Ultimately a much cleaner solution would be to approach it like TLM-2.0, with the Direct Memory Access happening as part of the normal port access. Then each master could get a pointer straight into the memory, and the memory is responsible for invalidating/managing the pointers it has handed out. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1046/#review2191 ----------------------------------------------------------- On Feb. 16, 2012, 10:44 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1046/ > ----------------------------------------------------------- > > (Updated Feb. 16, 2012, 10:44 a.m.) > > > Review request for Default. > > > Description > ------- > > CPU: Round-two unifying instr/data CPU ports across models > > This patch continues the unification of how the different CPU models > create and share their instruction and data ports. Most importantly, > it forces every CPU to have an instruction and a data port, and gives > these ports explicit getters in the BaseCPU (getDataPort and > getInstPort). The patch helps in simplifying the code, make > assumptions more explicit, andfurther ease future patches related to > the CPU ports. > > The biggest changes are in the in-order model (that was not modified > in the previous unification patch), which now moves the ports from the > CacheUnit to the CPU. It also distinguishes the instruction fetch and > load-store unit from the rest of the resources, and avoids the use of > indices and casting in favour of keeping track of these two units > explicitly (since they are always there anyways). The atomic, timing > and O3 model simply return references to their already existing ports. > > > Diffs > ----- > > src/cpu/base.hh ef8630054b5e > src/cpu/base.cc ef8630054b5e > src/cpu/base_dyn_inst.hh ef8630054b5e > src/cpu/inorder/InOrderCPU.py ef8630054b5e > src/cpu/inorder/cpu.hh ef8630054b5e > src/cpu/inorder/cpu.cc ef8630054b5e > src/cpu/inorder/resource.hh ef8630054b5e > src/cpu/inorder/resource_pool.9stage.cc ef8630054b5e > src/cpu/inorder/resource_pool.hh ef8630054b5e > src/cpu/inorder/resource_pool.cc ef8630054b5e > src/cpu/inorder/resources/cache_unit.hh ef8630054b5e > src/cpu/inorder/resources/cache_unit.cc ef8630054b5e > src/cpu/o3/cpu.hh ef8630054b5e > src/cpu/o3/cpu.cc ef8630054b5e > src/cpu/o3/fetch_impl.hh ef8630054b5e > src/cpu/o3/iew_impl.hh ef8630054b5e > src/cpu/o3/lsq_impl.hh ef8630054b5e > src/cpu/simple/atomic.hh ef8630054b5e > src/cpu/simple/atomic.cc ef8630054b5e > src/cpu/simple/base.hh ef8630054b5e > src/cpu/simple/timing.hh ef8630054b5e > src/cpu/simple/timing.cc ef8630054b5e > src/cpu/thread_state.cc ef8630054b5e > src/kern/tru64/tru64_events.cc ef8630054b5e > src/mem/fs_translating_port_proxy.cc ef8630054b5e > > Diff: http://reviews.gem5.org/r/1046/diff/diff > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
