> 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. > > Andreas Hansson wrote: > 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.
It's useful if you want to warm up the cache contents while running at reasonable speed. You're right that a TLM-like direct memory access extension would be an even more effective and cleaner solution. Guess we should put that on the to-do list ;-). For now I suppose there's no reason to rip the extra port out until we do get to the point of adding the direct memory access. - Steve ----------------------------------------------------------- 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
