Looks like a few of these issues are up my alley. I've been out of town for the weekend, so I will take a strong look at these after I get back tonight.
On a first look, I'm thinking that the "activateWhenReady" code could be safely removed since individual threads changing from active to unallocated to active (old terminology) isn't stressed in SE mode I dont believe. On Sat, Mar 28, 2009 at 5:05 PM, Steve Reinhardt <[email protected]> wrote: > OK, I've finally gotten around to attacking this thread context status > issue; for starters, I'm just trying to get rid of the Unallocated > state and merge it with the Halted state. The only places that are > giving me trouble are spots in O3 and In > > Most of the places where a thread is set to Unallocated are in the > various deallocate() methods of the thread context classes and CPU > models. Clearly if we no longer have an Unallocated state then we > should just get rid of that method. It's only called from two places, > one of which is the Tru64-only m5_thread_exitFunc (part of the > hacked-in SPLASH support, and the source of all this trouble), which > was easy enough to change to call tc->halt() instead. The other place > it's called though is in > InOrderThreadContext::setThreadRescheduleCondition, a function that > doesn't appear to be called from anywhere itself, so it's hard to say > what it's supposed to be doing. > > Another spot where it wasn't obvious what to do is in > O3ThreadContext<Impl>::activate(int delay): > > if (thread->status() == ThreadContext::Unallocated) { > cpu->activateWhenReady(thread->threadId()); > return; > } > > I think this is an example of O3 thinking that Unallocated means "no > microarchitectural resources allocated" and not "no software thread > assigned". The activateWhenReady function itself is only called from > one other place that's part of this context switching mechanism that I > didn't even know existed that's in O3. Does that code work? > > My bias at this point is to just remove any code that looks like it > probably doesn't work now and thus will become even farther from > working if I have to change it in order to compile without the > Unallocated state. If these bits of code actually do work, please let > me know ASAP, and help me figure out how to keep them working after > the Unallocated state is gone. > > Thanks, > > Steve > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > -- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
