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 >>> >>> >> >> >> >> > > -- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
