> On Aug. 20, 2015, 4:30 p.m., Steve Reinhardt wrote: > > I have mixed feelings about this patch---on the one hand, the uniformity of > > all CPU models supporting SMT is nice. On the other hand, the idea of the > > SimpleCPU classes was for them to be simple, and this is a big step away > > from that. > > > > My initial thought was that you could warm up the L1 cache for a > > four-thread SMT detailed CPU by using four single-threaded simple CPUs, but > > I guess if you're in FS mode and you have some per-core (not per-thread) > > OS-visible state then that would get tricky. Is that the case? > > > > If we are going to stick with an SMT SimpleCPU, it would be nice to > > restructure things a little more, rather that just putting for loops and > > "tinfo." all over. For example, can we define a SimpleCPUThread object and > > move a lot of the code to that? That would get rid of a lot of the > > "tinfo." all over the place. Also, part of the idea of the SimpleCPU > > models is that they provide an example of the minimum that needs to be done > > to turn the ISA description into a functional model; if SimpleCPUThread > > could play that role instead, I'd feel better about the added complexity in > > SimpleCPU itself. > > > > Also, with all the code that's moved out of base.hh and into > > exec_context.hh it's hard to tell what if anything has changed there. It > > would be nice if that reorganization was packaged as a separate patch.
Re: SMT in Simple? I had originally considered doing the “hack” of just running multiple CPUs and then restoring on an SMT-enabled detailed CPU (either via checkpoint or modifying the existing switch logic to assign multiple threads from different CPUs to a single CPU). Doing this would have added specific configuration scripts/logic to re-write checkpoints and require additional gem5 parameters to tell the switch logic how many cores/threads to condense onto a single core. It seemed like a pretty big hack and the plumbing to do it a bit fragile, so I opted enable SMT on atomic/timing. By doing it this way, we get to leverage all of the existing gem5 code. We can dynamically switch back and forth between detailed/atomic/timing (to get to regions of interest / fast-forward). Getting all of the advantages of cache warming, etc. Re: Taking thread-specific code out of SimpleCPU and creating a SimpleCPUThread Thats kind of what the existing ThreadInfo is doing, the simple CPU will always have to have a way to index to a specific thread context (and iterate over all possible ones). One thing that could be done to limit the visibility is to have a pointer *curThreadInfo in the atomic/timing base class, that way we’d avoid the lookup based upon “curThread” at the beginning of some functions. That'd save 2 lines in about 12 places. But I don’t see a way around for loops iterating across threads in things like snoop logic or drainResume() where we have to check the status of each thread. Re: ExecContext vs Base It’s a close-to direct copy of the existing functionality. All regressions pass with these SMT patches applied (no stat changes whatsoever). This patch has been pretty thoroughly tested. Linux successfully boots with 4-way SMT atomic/timing and minor (to be posted soon). - Mitch ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2995/#review7018 ----------------------------------------------------------- On July 30, 2015, 6:47 p.m., Curtis Dunham wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2995/ > ----------------------------------------------------------- > > (Updated July 30, 2015, 6:47 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Adds SMT support to the "simple" CPU models so that they can be used > with other SMT-supported CPUs. Example usage: have the TimingSimpleCPU > warmup caches before swapping to detailed mode with the in-order or > out-of-order based CPU models. > > > Diffs > ----- > > src/cpu/simple/base.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 > src/cpu/simple/base.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 > src/cpu/simple/exec_context.hh PRE-CREATION > src/cpu/simple/timing.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 > src/cpu/simple/timing.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 > tests/quick/se/01.hello-2T-smt/test.py > 40526b73c7db9ff2e03215cdfb477d024ea8d709 > src/cpu/simple/atomic.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 > src/cpu/simple/atomic.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 > configs/example/se.py 40526b73c7db9ff2e03215cdfb477d024ea8d709 > > Diff: http://reviews.gem5.org/r/2995/diff/ > > > Testing > ------- > > > Thanks, > > Curtis Dunham > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
