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

Reply via email to