Hello, So if we want to keep track of bus transfer latency, we need to look at the function: bool Bus::recvTiming(PacketPtr pkt) under src/mem/
I presume this function will be called twice, first by the L2 (when L1 sends) and by L1(when L2 sends back). So if we want to consider total miss penalty we should take a look at this function? On a related note from my understanding timing is really calculated here: Tick Bus::calcPacketTiming(PacketPtr pkt) under src/mem/ Thanks On Tue, Apr 28, 2009 at 11:50 AM, Steve Reinhardt <[email protected]> wrote: > Looks to me like you're on the right track. > > The point of the whenReady field is to take care of a possible glitch due > to the fact that we don't model the cache in a completely detailed > cycle-by-cycle fashion; the first miss is satisfied assuming a > critical-word-first response, but a subsequent miss should have to wait for > the entire block to arrive, and this makes sure that a subsquent miss that > happens during that transfer window doesn't get an artificially early > response. In practice it probably isn't triggered much though so I doubt it > affects results much. > > All the values you're looking at just affect the cache response latency; > you also have to factor in the bus transfer latency (which you pay for in > both directions) if you want to consider the total miss penalty for that one > level of cache. > > Steve > > > 2009/4/25 ef <[email protected]> > >> Hi, >> I want to dynamically change the latency of retrieving blocks in the cache >> on the fly. So for example if L1 wants to gets data from the L2 cache I >> want to change the latency of finding a certain cache block i.e. making it >> twice as fast (half the latency). I have a clear cut idea on how to do this, >> however I also have some questions and wanted to confirm my understanding of >> M5 code. >> >> in mem/cache/cache_impl.hh we have the following function: >> >> >> // Access path: requests coming in from the CPU side >> >> template<class TagStore> bool Cache<TagStore>::access(PacketPtr pkt, >> BlkType *&blk,int &lat, PacketList &writebacks) >> >> in this function latency is calculated here: >> >> blk = >> tags<http://www.m5sim.org/docs/classCache.html#fe773e2c71e31381a91bbccae20b4a37> >> ->findBlock(pkt->getAddr<http://www.m5sim.org/docs/classPacket.html#1c04785186ba5aa70a40cac9b2bfc86e>(), >> lat); //lat=latency >> Th easiest implementation is to add: >> (1)* lat=lat/2; >> after findblock is executed in access(). My question is, is that correct? >> >> So findblock is defined as: >> >> LRUBlk* LRU::findBlock(Addr addr, int &lat) and is located in >> Src/mem/cache/blk.cc && .hh >> where latency is calculated as: >> lat = hitLatency; >> Which seems fine, however I can't figure out when/why the latency is >> changed here in findBlock(): >> >> >> if (blk->whenReady > curTick && blk->whenReady - curTick > hitLatency) { >> >> lat = blk->whenReady - curTick; >> >> } >> I can't seem to understand the code and when exactly the if statement >> is executed. This if statement and redefinting latency could potentially >> make my "idea" of (1)* incorrect. So could someone please help me figure out >> what this code is saying? >> >> Also say that when L1 requests a specific block(one that is faster) from >> the L2 cache, >> I will do this under L2: >> latency=latency/2 , >> from what I figure this is reducing the roundtrip time which is what I >> want, is this correct or is this reducing one way latency by half (ie L2 >> back to L1). >> >> >> Thanks, >> EF >> >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
