2009/3/17 Korey Sewell <[email protected]>: > I'd go with Active, Suspended, and Unallocated. > > In my interpretation, the threads start in Suspended state because that > meant that you've allocated registers for that thread but it currently isn't > running. While Unallocated or Halted would mean that the CPU has no > knowledge or register binding for a particular thread. > > So I actually think starting a thread as "Suspended" makes sense. Maybe a > better term would be "Inactive" since it would be everything that a "Active" > thread has save for it running on a CPU.
Actually I think that part of the problem we have now is that there isn't enough (or any?) separation between the ThreadContext-level thread status, which is primarily the software's view of the thread state, and the microarchitectural view, specifically in O3. There's really no requirement that there be any microarchitectural change in register bindings once a thread enters the "unallocated" state; that's a microarchitectural policy decision. In fact it sounds like there's some confusion over the word "unallocated" even; it's intended to mean that the SW hasn't allocated this thread context to a task yet, which (again) is somewhat independent of whether the microarchitecture has allocated resources to the thread context. Similarly I would want Suspended to mean that the thread was suspended through some direct software action, like the HLT or MWAIT instruction, while a purely microarchitectural "suspended" state (e.g., because the thread is stalled on a long-latency memory operation) would be reflected only in the CPU model's internal data structures. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
