It does work for smtNumFetchingThreads=1. -Rick
Steve Reinhardt wrote: > I'm just wondering if you configure it to only fetch from at most one > thread per cycle if this problem will go away. > > On Sun, Jul 6, 2008 at 4:00 PM, Rick Strong <[EMAIL PROTECTED]> wrote: > >> There is a round robin policy that fetches from multiple threads. >> >> -Rick >> >> Steve Reinhardt wrote: >> >>> Thanks for tracking this down... it validates with my theory that the >>> new SE-mode address translation is the culprit, since before that was >>> added you never would have had a fault in SE mode. >>> >>> Unfortunately I'm no O3 expert, so I can't give you any pointers on >>> how to solve the problem off the top of my head. I am a little >>> curious about why both threads would be fetching in the same cycle >>> though; I'd expect the SMT model to choose one thread or the other to >>> fetch from but not both. Is there a policy to enable this behavior? >>> I'm more familiar with the SMT that Steve Raasch added to the old >>> obsolete SimpleScalar-derived CPU though, and not so much with what >>> Korey's done to O3. >>> >>> Steve >>> >>> On Sun, Jul 6, 2008 at 3:24 PM, Rick Strong <[EMAIL PROTECTED]> wrote: >>> >>> >>>> After diving into this problem more, it seems that there might be a >>>> problem in src/cpu/o3/fetch_impl.hh for SMT in general. At the bottom >>>> of function fetch(), if a fault has occurred, a no-op instruction is >>>> formed and placed in the toDecode wire. However, the reference that is >>>> used is "toDecode->insts[numInst] = instruction;" at line 1256 where >>>> numInsts is never incremented. The end result is that if two SMT threads >>>> both fault on the fetch tick when using EIO traces, they both write to >>>> the same location in the insts field of the toDecode struct. Attempted >>>> to solutions that have not worked. >>>> >>>> 1) If I increment numInst afterwards, it seems that it is possible to >>>> fetch more instructions than the width due to the insertion of the >>>> no-ops. >>>> >>>> 2) If I use toDecode->size value before it is increment on line 1258 >>>> (approx.), this leads to a null access sometime later down the road. >>>> >>>> If someone has a good understanding with O3 or SMT implementation, your >>>> help would be appreciated. >>>> >>>> -Rick >>>> >>>> >>>> >>> >> > > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
