So in order of preference, my vote for the 3 state names would be: 1) Active, Inactive, Unallocated 2) Active, Suspended, Unallocated 3) Active, Halted, Unallocated
Halt seems like a word that has it's own interpretations for different ISAs so might be best for M5 not to get tangled in that web with it's own meaning of Halt. On Tue, Mar 17, 2009 at 8:43 AM, Korey Sewell <[email protected]> wrote: > 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. > > > On Tue, Mar 17, 2009 at 3:37 AM, Gabe Black <[email protected]> wrote: > >> Steve Reinhardt wrote: >> > 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 >> > >> I think Ali was the one that implemented the SPARC register you ask >> about in 1. The x86 halt instruction does put you into a suspended state >> where you'll wake back up if you get an interrupt. Another item for your >> list could be that some CPU models are unwilling to start a thread as >> suspended. Your three state system seems like a better idea than the old >> four state one. >> >> Gabe >> _______________________________________________ >> 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 > -- ---------- 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
