Hi Max, SMT has definitely worked as there are even "SwitchOnCacheMiss" thread handling options that I added to InOrder when I did some SMT research studies. I've actually seen it work for up to 16 threads so it's a bit of a surprise that it's seems so broken now. I would think one or two small fixes would bring us back up given the recent changes added to gem5.
In any event, I'm not very useful on gem5 throughout the working day but what I can do is run SMT on InOrder when I get home and report on what I get back from the simulator at the top of the tree. It may be some misconfigurations by default or if there are some small errors that get this back to a steady state I can make those fixes too. On Thu, Sep 27, 2012 at 6:31 AM, Maximilien Breughe < [email protected]> wrote: > Hi Korey, > > Thanks for your fast response! > > I did recompile the model and I think I discovered a first place where > things go wrong: the fetchprioritylist doesn't get properly initialized. > The functionality to do this is written in the function FirstStage::setCPU > of first_stage.cc. However this function never gets called. The reason for > this is that in pipeline_stage.cc the function setCPU is not declared as > "virtual". Adding this keyword in front of the function resolves the > Segmentation fault but unfortunately the simulator aborts a little bit > later: > > gem5.opt: build/ALPHA/cpu/inorder/resources/fetch_unit.cc:588: virtual > void FetchUnit::trap(Fault, ThreadID, ThePipeline::DynInstPtr): Assertion > `pendingFetch.size() == 0' failed. > Program aborted at cycle 56500 > > Does SMT on an InOrderCPU works for you, Korey? > > Thank you, > > Max > > > On 09/26/2012 05:27 PM, Korey Sewell wrote: > > Hi Max, > Did you recompile the model after changing MaxThreads? > > In terms of debugging, > Can you locate the code that populates the fetchprioritylist? Can you > double check that a change in MaxThreads is setting up that list correctly? > > -Korey > > On Wed, Sep 26, 2012 at 7:51 AM, Maximilien Breughe < > [email protected]> wrote: > >> Hi, >> >> I would like to run multiple programs on an inorder core which supports >> SMT. >> For this I needed to replace MaxThreads = 1 by (e.g.) MaxThreads = 2 in >> src/cpu/inorder/pipeline_traits.hh. >> However, running the simulator with smt enabled for an inorder core >> results into a Segmentation fault. >> Does anyone have an idea? >> >> To run two instances of "hello world" on an inorder core I use: >> build/ALPHA/gem5.opt configs/example/se.py >> --cmd=tests/test-progs/hello/bin/alpha/linux/hello;tests/test-progs/hello/bin/alpha/linux/hello >> --cpu-type=inorder --caches --smt >> >> The same command on a "detailed" cpu works fine, but running this command >> for an inorder cpu results into a segmentation fault. Gdb told me that >> there is a problem on this line: >> FirstStage::roundRobin (this=0x27670d0) at >> build/ALPHA/cpu/inorder/first_stage.cc:255. >> This is the line of code causing the problem: >> list<ThreadID>::iterator pri_iter = fetchPriorityList->begin(); >> >> >> Kind regards, >> >> Max >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > -- > - Korey > > > _______________________________________________ > gem5-users mailing > [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
