Sure, it is recording all miss latencies, including L1 cache hits. And yes, those L1 hits will show up in the first bucket. However, I don't see how that is a bug. If you don't want to include L1 hits in the histogram, then look how the MOESI_hammer protocol tracks separate miss latencies depending on the responding machine type.
Brad > -----Original Message----- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On > Behalf Of Korey Sewell > Sent: Wednesday, April 20, 2011 7:20 PM > To: M5 Developer List > Subject: Re: [m5-dev] Defining Miss Latencies in Ruby > > (comments inline) > > > I'm confused. The miss_latency calculated by the sequencer is the > miss > > latency of the particular request, not just L1 cache hits. > > > I think I understand that, but even if it's just L1 hits, let's say > that the > L1 latency is 1 and you are running a workload with a high hit rate in > the > L1s. Then doesnt the code then continuously record that L1 hit in the > 1st > histogram bucket? This would definitely be the case for L1 latencies of > the > more than 1, since it's hardcoded to record everything of a latency > 0 > (basically all requests), right? > > > > > > If you're seeing a bunch of minimum latency requests, I suspect > something > > else is wrong. > > For instance, is "issued_time" a cycle value or a tick value? > > > The issued_time is the cycles, as it is set in the makeRequest(), > Sequencer > function when a new Request is built. > -- > - Korey > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev