Ok. I can wait, I just wanted to make sure it didn't get forgotten. Gabe
Steve Reinhardt wrote: > I still have a patch in my queue, but between vacation two weeks ago > and catching up with having been on vacation last week I have not > touched it recently. It "mostly" works but there was one problem that > kept me from committing it (can't recall the details off the top of my > head though... something with O3 I think). I may have a chance to get > back to it in the later part of this week. If you want to work on it I > can send you the patch. > > Steve > > On Sun, Apr 12, 2009 at 1:22 PM, Gabe Black <[email protected]> wrote: > >> 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 >> >> > _______________________________________________ > 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
