I'm running into yet more problems with the varying interpretations of
thread status, so I'd like to get this cleared up. For reference,
here's the current enum in thread_context.hh:
enum Status
{
/// Initialized but not running yet. All CPUs start in
/// this state, but most transition to Active on cycle 1.
/// In MP or SMT systems, non-primary contexts will stay
/// in this state until a thread is assigned to them.
Unallocated,
/// Running. Instructions should be executed only when
/// the context is in this state.
Active,
/// Temporarily inactive. Entered while waiting for
/// synchronization, etc.
Suspended,
/// Permanently shut down. Entered when target executes
/// m5exit pseudo-instruction. When all contexts enter
/// this state, the simulation will terminate.
Halted
};
Those definitions seem reasonable, but the usage is very inconsistent.
Here are just a few things that appear to be happening:
- Though the SimpleCPU models follow the comments and initialize
threads in Unallocated, the O3 and InOrder CPUs initialize threads to
Suspended. I haven't tried this recently, but I recall that simply
changing the initialization code in O3 to start in Unallocated causes
other things to break.
- Even though the comment says that a thread in the Halted state is
"permanently" halted, the MIPS MT implementation appears to use this
state for something that looks more like a software-controlled
suspend.
- The Halted state is entered via some Alpha PAL instruction (maybe
cause by m5exit as the comment indicates), but an exit() call in SE
mode causes a thread to move back to Unallocated rather than Halted.
- The SPARC readFSReg function in ua2005.c looks like it is supposed
to return thread status information to the guest, and only has cases
for Active, Suspended, and Halted (and will panic if it ever queries a
thread that's Unallocated).
- Other than the SPARC function mentioned above, I don't see anything
that ever looks to see if a thread is in the Halted state (i.e., it's
almost write-only).
It seems to me that we ought to be able to get away with just three states:
1. Active: no confusion there
2. Temporarily inactive (think "paused")... what is basically
Suspended now, though I'm still confused about why InOrderCPU and O3
initialize threads to this state.
3. Stopped, basically combining both Halted and Unallocated.
The basic difference between #2 and #3 is that in #2 the thread
context has a software thread assigned to it but is just waiting to
resume execution, where in #3 there is no software thread assigned to
the context. I'm inclined to keep the Suspended and Halted names,
though this would be a good time to pick new ones if anyone felt that
would be helpful. (Particularly given that I expect the "halt"
instruction in x86 if not in other ISAs to actually move a thread to
Suspended rather than Halted, we may want to pick a different name for
state #3.)
I expect there's no way to really know whether a particular scheme
will work except to try it, but any comments or insight anyone could
provide up front would be helpful. I'm particularly curious about (1)
what if any semantics SPARC attributes to these various states based
on their exposure to software in the misc reg mentioned above and (2)
why it would matter that a CPU is initialized to Suspended rather than
Halted or Unallocated (since I know Gabe, Polina, and Ali have all
wrestled with this in FS mode recently).
Thanks,
Steve
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
