Comments below:
> The other place it's called though is in
> InOrderThreadContext::setThreadRescheduleCondition, a function that
> doesn't appear to be called from anywhere itself, so it's hard to say
> what it's supposed to be doing.
That function is supposed to be called from arch/mips/mt.hh where a
yieldThread() is initiatied by a MIPS MT YIELD instruction and sets some
user-defined condition for that thread to restart. I interpreted the right
thing to do there was release the thread's register bindings (deallocate),
set it to Suspended, and then activate it based on some user-defined
condition (a cycle delay on a first cut).
I think the right thing to do there would be to remove that deallocate()
line in ThreadContext and it would be OK for a thread-reschedule to suspend
the thread & activate when necessary.
> Another spot where it wasn't obvious what to do is in
> O3ThreadContext<Impl>::activate(int delay):
>
> if (thread->status() == ThreadContext::Unallocated) {
> cpu->activateWhenReady(thread->threadId());
> return;
> }
>
> I think this is an example of O3 thinking that Unallocated means "no
> microarchitectural resources allocated" and not "no software thread
> assigned". The activateWhenReady function itself is only called from
> one other place that's part of this context switching mechanism that I
> didn't even know existed that's in O3. Does that code work?
I see the confusion there. That code *had* purpose but now might be wackable
with the clarification of Thread Context. Basically, the activateWhenReady
prevents a thread from starting on the O3CPU without enough resources
otherwise it will just stall/deadlock the system.
I would assume that a CPU has to have that type of sanity check before
legitimately starting a thread or maybe that is done through some interface
with the OS and perf. counters. For instance, doesnt the Pentium 4
hard-split resources amongst the 2 threads? If so, before adding a thread it
would have to some mechanism to wait for the resources to balance out before
allocating threads or at the very least prioritize the new thread. So, that
code mostly had that type of purpose when dynamically adding SMT threads to
ensure the pipeline isnt overcommitted to other thread(s).
Can it be wacked? If we are saying that that is too much functionality to
hard-code into the CPU, then sure.
It's unclear what is the *exact* right thing to do there so it might be OK
to leave it to the OS or some other mechanism to check resources before
assigning multiple threads to a CPU.
Also, since there is no more "Unallocated" state (only Suspended or Halted),
then when would that "activateWhenReady" be useful? Like I detailed earlier,
situations where threads are being started/stopped across SMT CPUs woud
really stress this type of code but currently no regressions or applications
do this.
Thus, I'll go with your (Steve's) theory of removing code that isn't
explicitly useful at the moment so I'd be OK with removing it and if it is
ever needed it would be nothing to add it as necessary (and having a
regression that validates its correctness as code changes).
If we are removing that function, the related "insertThread" and
"doContextSwitch" O3 functions would also be candidates for removal as
well.
--
----------
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
