I don't really know anything about the situation here, but is it possible to just call a function to take care of the thread activation at the end of the tick event? I'm making the assumption that every time a thread is activated a tick should have already happened for that instant.
Gabe Korey Sewell wrote: > # HG changeset patch > # User Korey Sewell <[email protected]> > # Date 1265078642 18000 > # Node ID 42577d95f31471f661ce7337f290578f9d324374 > # Parent a3a20caba7014ca897860c5ff6619cfa6bbaa43a > inorder/sim: add thread activation priority > > diff --git a/src/cpu/inorder/cpu.cc b/src/cpu/inorder/cpu.cc > --- a/src/cpu/inorder/cpu.cc > +++ b/src/cpu/inorder/cpu.cc > @@ -85,9 +85,8 @@ > > InOrderCPU::CPUEvent::CPUEvent(InOrderCPU *_cpu, CPUEventType e_type, > Fault fault, ThreadID _tid, DynInstPtr inst, > - unsigned event_pri_offset) > - : Event(Event::Priority((unsigned int)CPU_Tick_Pri + event_pri_offset)), > - cpu(_cpu) > + Event::Priority event_pri) > + : Event(event_pri), cpu(_cpu) > { > setEvent(e_type, fault, _tid, inst); > } > @@ -666,10 +665,10 @@ > void > InOrderCPU::scheduleCpuEvent(CPUEventType c_event, Fault fault, > ThreadID tid, DynInstPtr inst, > - unsigned delay, unsigned event_pri_offset) > + unsigned delay, Event::Priority event_pri) > { > CPUEvent *cpu_event = new CPUEvent(this, c_event, fault, tid, inst, > - event_pri_offset); > + event_pri); > > if (delay >= 0) { > DPRINTF(InOrderCPU, "Scheduling CPU Event (%s) for cycle %i, > [tid:%i].\n", > @@ -875,7 +874,8 @@ > DPRINTF(InOrderCPU,"[tid:%i]: Activating ...\n", tid); > > > - scheduleCpuEvent(ActivateThread, NoFault, tid, dummyInst[tid], delay); > + scheduleCpuEvent(ActivateThread, NoFault, tid, dummyInst[tid], delay, > + Event::CPU_Thread_Activation_Pri); > > // Be sure to signal that there's some activity so the CPU doesn't > // deschedule itself. > @@ -893,7 +893,7 @@ > // threads after we've finished deactivating, squashing,etc. > // other threads > scheduleCpuEvent(ActivateNextReadyThread, NoFault, 0/*tid*/, > dummyInst[0], > - delay, 5); > + delay, Event::CPU_Thread_Activation_Pri); > > // Be sure to signal that there's some activity so the CPU doesn't > // deschedule itself. > diff --git a/src/cpu/inorder/cpu.hh b/src/cpu/inorder/cpu.hh > --- a/src/cpu/inorder/cpu.hh > +++ b/src/cpu/inorder/cpu.hh > @@ -209,7 +209,7 @@ > public: > /** Constructs a CPU event. */ > CPUEvent(InOrderCPU *_cpu, CPUEventType e_type, Fault fault, > - ThreadID _tid, DynInstPtr inst, unsigned event_pri_offset); > + ThreadID _tid, DynInstPtr inst, Event::Priority event_pri); > > /** Set Type of Event To Be Scheduled */ > void setEvent(CPUEventType e_type, Fault _fault, ThreadID _tid, > @@ -238,7 +238,7 @@ > /** Schedule a CPU Event */ > void scheduleCpuEvent(CPUEventType cpu_event, Fault fault, ThreadID tid, > DynInstPtr inst, unsigned delay = 0, > - unsigned event_pri_offset = 0); > + Event::Priority event_pri = Event::CPU_Tick_Pri); > > public: > /** Interface between the CPU and CPU resources. */ > diff --git a/src/sim/eventq.hh b/src/sim/eventq.hh > --- a/src/sim/eventq.hh > +++ b/src/sim/eventq.hh > @@ -221,6 +221,12 @@ > /// (such as writebacks). > CPU_Tick_Pri = 50, > > + /// Thread Activations on the CPU need to take place after > + /// the CPU completes a tick so that we aren't prematurely > + /// activating a thread before all the relevant resources > + /// are allocated correctly > + CPU_Thread_Activation_Pri = 60, > + > /// Statistics events (dump, reset, etc.) come after > /// everything else, but before exit. > Stat_Event_Pri = 90, > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
