This seems to have fallen off the map. Is anybody working on this right
now? My queue is getting pretty deep again and this is what's holding up
the oldest patches. About 10 patches after that we'll need to automate
setting up BIOS tables. Right now I have a manual hack that forces you
to have two CPUs instead of forcing you to have one CPU, and that's
obviously not ideal.
Gabe
Korey Sewell wrote:
> 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
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
