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

Reply via email to