Do you mean (1) or (2)? I thought that with (1) the stats would not change.
My bias would be (2), but (1) seems livable enough. In either case it would be nice to put in a warn_once() if we don't already have one so it's obvious that SW prefetches are being ignored. Steve On Sun, Oct 31, 2010 at 9:45 AM, Ali Saidi <[email protected]> wrote: > Any input? Otherwise I'm going with (1) and have new stats to go with it. > > Ali > > On Oct 27, 2010, at 12:02 AM, Ali Saidi wrote: > > > Hmmm... three emails when one should have done. There are three options: > > 1. Make them actual no-ops (e.g. stop marking them as mem refs, data > prefetch, etc). The instruction count will stay the same here. The > functionality will stay the same. The instructions will be further away from > working -- not that I think anyone will make them work in the future. > > 2. Leave them in their half bake memop state where they're memops that > never call read() and don't write back anything, so the instruction count is > different since the inst count gets incremented after the op completes. This > is what I currently have. > > 3. Make them actually work. I've tried to muck with this without success > for a while now. > > > > Ali > > > > > > > > On Oct 26, 2010, at 11:58 PM, Ali Saidi wrote: > > > >> The other portion of this, is when I try to make them act like loads, > but not actually write a register I break the o3 cpu in ways that 4 hours > has not been able to explain. > >> > >> Ali > >> > >> On Oct 26, 2010, at 10:42 PM, Ali Saidi wrote: > >> > >>> 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 > >>> > >> > >> _______________________________________________ > >> 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
