When I said prefetches "are only issued when there are no demand misses outstanding", I meant they are only issued when there is no demand miss also waiting to be issued. Once the demand miss has been issued, a prefetch can be issued whether or not the demand miss has completed.
More specifically, whenever the cache issues a request, it checks to see if it should re-request the bus for another request. This all happens at the end of Cache<TagStore>::MemSidePort::sendPacket(). Note that in spite of the comment about factoring in prefetch requests (I'm not sure where that came from), they do get considered via nextMSHRReadyTime(). So if there's no demand miss waiting but there is a prefetch available, the cache will re-request the bus. Then when the cache is granted the bus again, if there are no demand misses, it will issue a prefetch as long as one is available and the mshrQueue is not full (this is the code at the end of getNextMSHR() ). As I said, it's possible that there is a bug and this is not working as we expect it to. Feel free to trace through it in the debugger or add more DPRINTFs or do whatever you would like to verify its operation, and let us know if you find something suspicious. Steve On Tue, Feb 21, 2012 at 6:01 AM, Ali Saidi <[email protected]> wrote: > It issues a prefetch if the address it's trying to prefetch doesn't exist > in the mshr or write queue. You generally don't want to prefetch something > that you're currently waiting for. That is wasted bandwidth. > > Ali > > Sent from my ARM powered device > > On Feb 21, 2012, at 1:49 AM, Mahmood Naderan <[email protected]> wrote: > > I don't know if this implementation in gem5 is realistic. If the > prefetching is done when there is no entry in MSHR or write queue, then for > an application that suffers high number of misses, there is no opportunity > to issue a prefetch. > > However we want to prefetch to reduce number of misses. > > In another word, with current implementation, prefetching is issued for > applications which are happy with few number of misses. > -- > // Naderan *Mahmood; > > > On Mon, Feb 20, 2012 at 10:14 PM, Steve Reinhardt <[email protected]>wrote: > >> Hmm... the prefetcher should never cause the program to get the wrong >> answer. Are you using the latest code from the gem5 repository? >> >> As far as the number of prefetches, they are only issued when there are >> no demand misses outstanding. If your program is saturating the memory bus >> with misses then there may just not be an opportunity to generate many >> prefetches. Of course, there could also be a bug. You could check the >> code at the end of Cache<TagStore>::getNextMSHR() to see if the prefetcher >> is being called to provide prefetch addresses or not, and >> check Cache<TagStore>::nextMSHRReadyTime() to see if the prefetcher is >> appropriately signaling that it has prefetches to issue. >> >> Steve >> >> On Mon, Feb 20, 2012 at 9:37 AM, Mitchelle Rasquinha < >> [email protected]> wrote: >> >>> >>> >>> I am trying to use the stride prefetcher and see a similar problem with >>> the >>> dafault configuration. On increasing the prefetch degree > 2 the result >>> of the >>> benchmark is incorrect. What are the values for these knobs? >>> >>> prefetch_on_access = Param.Bool(True, >>> "notify the hardware prefetcher on every access (not just >>> misses)") >>> prefetcher_size = Param.Int(100, >>> "Number of entries in the hardware prefetch queue") >>> prefetch_past_page = Param.Bool(False, >>> "Allow prefetches to cross virtual page boundaries") >>> prefetch_serial_squash = Param.Bool(False, >>> "Squash prefetches with a later time on a subsequent miss") >>> prefetch_degree = Param.Int(1, >>> "Degree of the prefetch depth") >>> prefetch_latency = Param.Latency(5 * Self.latency, >>> "Latency of the prefetcher") >>> prefetch_policy = Param.Prefetch('stride', >>> "Type of prefetcher to use") >>> prefetch_use_cpu_id = Param.Bool(True, >>> "Use the CPU ID to separate calculations of prefetches") >>> prefetch_data_accesses_only = Param.Bool(True, >>> "Only prefetch on data not on instruction accesses") >>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
