This is for SE mode.
So I changed src/cpu/alpha/cpu_impl.hh to set the thread status to Unallocated if i >= params->workload.size(). I reverse the signs in activateWhenReady(...) of src/cpu/o3/cpu.cc, and modified LSQ<Impl>::numFreeEntries to return min(LQEntries -1, SQEntries -1) if activeThreads->size() == 0. However, the problem I have now is that each cpu must be assigned a workload in order to be instantiated (in this case, several dummy workloads). At this assignment all cpu thread contexts are assigned to Suspended. If I change this assignment of Unallocated, it appears that nothing is assigned to the eventq to run, as the simulation finishes in a few seconds. Do I need to assign the Suspended to one cpu and assign the rest to Unallocated? Thanks, -Rick Korey Sewell wrote: > This is SE or FS mode? ... > > Hmmmm, I kind of feel like this is a reoccurring problem since I > remember a mailing list thread way way back when Ron was real active > on M5 saying that he switched the threads to start off at Unallocated > to get SPLASH to work for O3. However, it's tagged and not fixed yet > as a bug report so I believe the flyspray thread captures the problem > appropriately... > > The fixes would be: > (1) switch the thread to start off as Unallocated and edit > activateWhenReady to handle this case now. > (2) switch over from SimpleCPU ... > > I think you can edit the activate() function like you say and > alleviate the problem. > > And on another end, this kind of motivates me the need to roll through > SMT regression tests back into M5 because without that > we can't really "re-prove" code works or not after subtle changes to > M5 inevitably happens... > > Until I can get that pushed, then I'm happy to help on bug fixes... > > I need to try to recreate your bug and look closely at it before I can > give further advice. > > On Mon, Oct 6, 2008 at 2:45 PM, Rick Strong <[EMAIL PROTECTED]> wrote: > >> This is just for creating new threads on a different O3CPU. I am using the >> script in configs/splash2/run.py, but when --detailed is used we run into >> the problem that O3CPU thread context is initially allocated as Suspended. >> If you try to add a hack that allocates O3CPU thread context as Unallocated, >> you run into the problem that no available resource can be found for a new >> thread in function activateWhenReady(...). I guess the hack to get around >> this to start everything as atomic or simple timing and then switch. >> However, it seems that a slight modification to >> O3ThreadContext<Implh>::activate could also solve the problem as long as we >> check that no thread currently exists? >> >> Best, >> -Rick >> >> Korey Sewell wrote: >> >>> Rick, >>> do we want to create new SMT threads or do we want to create new >>> threads on a different O3 CPU? >>> >>> On Mon, Oct 6, 2008 at 2:27 PM, Steve Reinhardt <[EMAIL PROTECTED]> wrote: >>> >>> >>>> If you take a look at the flyspray bugs I posted based on this you'll see >>>> that they're still outstanding: >>>> >>>> http://www.m5sim.org/flyspray/task/317 >>>> http://www.m5sim.org/flyspray/task/318 >>>> >>>> As the comments on these bug reports show, I tried a simple fix but it >>>> didn't work. The code for deciding when you can allocate new threads on >>>> the >>>> fly in O3 is basically broken (looks like it was never tested). At the >>>> time >>>> a general fix by anyone other than Korey looked too complicated. I don't >>>> know if Korey's looked into it or not (Korey?). >>>> >>>> It could be that if you don't want to use SMT then coming up with a fix >>>> that >>>> works only for the 0->1 transition might be easier, but of course a more >>>> general fix for N->N+1 would be better yet. >>>> >>>> Steve >>>> >>>> On Mon, Oct 6, 2008 at 10:21 AM, Rick Strong <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>> Hi all, >>>>> >>>>> So I tried to run splash benchmarks with more than 1 O3 cpu, and I get >>>>> the error message, "nxm_threade_create: no idle contexts available". It >>>>> appears that the O3CPU thread contexts are not being set to unallocated >>>>> according to some emails I saw involving Sujay Phadke. Did we ever >>>>> commit the fix to the O3CPU? If so, i don't see it. >>>>> >>>>> Best, >>>>> -Rick >>>>> >>>>> _______________________________________________ >>>>> m5-users mailing list >>>>> [email protected] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>>> >>>>> >>>> _______________________________________________ >>>> m5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>> >>>> >>>> >>> >>> >>> >> > > > > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
