I think that's also O3 specific. When the translation finishes, the CPU is not involved. It finds out later only if it hasn't already gone to sleep/run out of "activity". It needs to be brought into the picture so it can do it's O3 specific magic function calls.
Gabe On 02/12/11 11:55, Ali Saidi wrote: > Might need to call activityThisCycle() then, possibly followed by wakeCpu(). > Ali > > Sent from my ARM powered device > > On Feb 11, 2011, at 1:44 PM, Gabe Black <[email protected]> wrote: > >> I tried that and it didn't work. I remember seeing a place where wakecpu >> bails if the state isn't currently idle (apparently it's not, but I >> didn't actually check) and the thing that disables scheduling ticks >> checks the activity count or the current state. There's the O3 specific >> wakeCPU function, I think it was called, which you guys added to fetch, >> but for data translations things are managed by the dyninst and the >> common DataTranslation class which shouldn't be calling CPU specific >> functions. I'd like to implement the change I described regardless at >> some point, but the big reason I need to do it now is that I need to >> move the function that finishes the translation out of the CPU >> independent classes and into the CPU so it can call the CPU specific >> wake up function. >> >> Gabe >> >> On 02/12/11 11:41, Ali Saidi wrote: >>> All you probably need to do in this case is call wakecpu() in the >>> finishTranslation() implementation. >>> >>> Ali >>> >>> Sent from my ARM powered device >>> >>> On Feb 12, 2011, at 4:28 AM, Gabe Black <[email protected]> wrote: >>> >>>> I've been fiddling with X86_FS with O3, and determined that it's getting >>>> stuck because there's an outstanding DTLB translation but no other >>>> activity. The translation comes back, but the CPU has stopped checking >>>> for instructions that are ready to reissue and never wakes up. There was >>>> a recent change implemented for ARM in O3 that added two pass style >>>> execution for memory instructions with delayed translation. I'm going to >>>> attempt to rework that so the call back that happens when translation >>>> finishes actually calls into the CPU to make the instruction progress >>>> instead of setting some state in the instruction and expecting the CPU >>>> to poll it. That isn't going to be as clean as it might sound because >>>> there are a lot of templates and type issues to sort out, but with that >>>> in place the CPU will be notified the translation is done whether or not >>>> it's asleep. The flow of execution for memory instructions will >>>> hopefully be simpler as well. >>>> >>>> Gabe >>>> _______________________________________________ >>>> 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 _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
