The count gets smaller because since they don't actually access memory, they never complete and therefore they never increment the instruction count.
Ali On Oct 26, 2010, at 9:53 PM, Steve Reinhardt wrote: > I vote for updating the stats... it's really wrong that we ignored them > previously. > > On Tue, Oct 26, 2010 at 5:47 PM, Ali Saidi <[email protected]> wrote: > Ok. So next question. With the CPU model treating prefetches as normal memory > instructions the # of instructions changes for the timing simple cpu because > the inst count stat is incremented in completeAccess(). So, one option is to > update the stats to reflect the new count. The other option would be to stop > marking the prefetch instructions as memory ops in which case they would just > execute as nop. Any thoughts? > > Ali > > > > > > On Oct 24, 2010, at 12:14 AM, Steve Reinhardt wrote: > > > No, we've lived with Alpha prefetches the way they are for long enough > > now I don't see where fixing them buys us that much. > > > > Steve > > > > On Sat, Oct 23, 2010 at 6:13 PM, Ali Saidi <[email protected]> wrote: > >> Sounds goo to me. I'll take a look at what I need to do to implement it. > >> Any arguments with the Alpha prefetch instructions staying nops? > >> > >> Ali > >> > >> On Oct 22, 2010, at 6:52 AM, Steve Reinhardt wrote: > >> > >>> On Tue, Oct 19, 2010 at 11:14 PM, Ali Saidi <[email protected]> wrote: > >>>> > >>>> I think the prefetch should be sent the the TLB unconditionally, and > >>>> then if the prefetch faults the CPU should toss the instruction rather > >>>> than the TLB returning no fault and the CPU i guess checking if the PA > >>>> is set? > >>>> > >>>> I agree that we should override the fault in the CPU. Are we violently > >>>> agreeing? > >>> > >>> OK, it's becoming a little clearer to me now. I think we're agreeing > >>> that the TLB should be oblivious to whether an access is a prefetch or > >>> not, so that's a start. > >>> > >>> The general picture I'd like to see is that once a prefetch returns > >>> from the TLB, the CPU does something like: > >>> > >>> if (inst->fault == NoFault) { > >>> access the cache > >>> } else if (inst->isPrefetch()) { > >>> maybe set a flag if necessary > >>> inst->fault = NoFault; > >>> } > >>> > >>> ...so basically everywhere else down the pipeline where we check for > >>> faults we don't have to explicitly except prefetches from normal fault > >>> handling. > >>> > >>> If there are points past this one where we really care to know if a > >>> prefetch accessed the cache or not, then maybe we need a flag to > >>> remember that (sort of a dynamic version of the NO_ACCESS static > >>> flag), but I don't know if that's really necessary or not. Clearly if > >>> the cache access doesn't happen right there, then we can add the flag > >>> and use it later to decide whether to access the cache. > >>> > >>> Anyway, this is the flavor I was going for... any issues with it? > >>> > >>> Steve > >>> > >> > >> > > > > _______________________________________________ > 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
