OK, might as well just pick something and move ahead and leave as many breadcrumbs as possible so we can go back to it later if we decide to.
Steve On Tue, Nov 2, 2010 at 2:39 PM, Ali Saidi <[email protected]> wrote: > There is a NO_ACCESS reference that is implemnted in the simple CPU, but > not in the O3 CPU. Ultimately, it's a couple of lines of code difference > between (1) and (2). I've also written the isa description for (3), so I'm > even up for revisiting it after we get prefetches working with other x86 or > arm in O3 and seeing if it's fixed. > > > > Ali > > > > > > On Tue, 2 Nov 2010 13:12:17 -0700, Steve Reinhardt <[email protected]> > wrote: > > Aren't there other NO_ACCESS references (in other ISAs) that call > initiateAcc() but not completeAcc()? If so, then that by itself doesn't > seem like justification to avoid solution (2). If not, then I suppose I > agree with you. > > Steve > > On Tue, Nov 2, 2010 at 12:54 PM, Ali Saidi <[email protected]> wrote: > >> Unfortunately, the stats change in all cases. For (1) the instructions no >> longer have IsMemRef set which means the num_refs changes for all CPUs and >> the change causes some minor changes in the O3. With (2) they're half baked, >> so the models call initiateAcc() but it doesn't actually initiate the >> access, so completeAcc() is never called and thus they aren't counted as >> part of the instruction count. (2) isn't ideal since half-calling the >> initiateAcc() might lead to some problems down the road. >> >> I'll post a diff today. >> >> Ali >> >> >> >> >> >> On Tue, 2 Nov 2010 12:18:08 -0700, Steve Reinhardt <[email protected]> >> wrote: >> >> 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 >> >> > > > _______________________________________________ > 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
