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
