On Mar 17, 2009, at 3:10 PM, Steve Reinhardt wrote: > 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. Yes.
> 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. Yes. > > > 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. Yes, too... I think this is also where some of the confusion about the idle O3 cpu statistics comes from. Ali _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
