Ha...those latency values have been referred to as miss latencies for so long that I failed to realize that calling them miss latencies would be confusing. There is a lot of old history there, more than I care to go into. If you want to change the name to request latency, that is fine by me.
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 9:24 PM > To: M5 Developer List > Subject: Re: [m5-dev] Defining Miss Latencies in Ruby > > Hi Brad, > Don't you think this is a misnomer and instead should be called > "request_latency:" , "request_latency_IFETCH", and etc.? I think this is what > is really being measuring anyway: the request latency from when a request > leaves the cpu sequencer and then eventually finishes. > > But if you are going to say a stat is "miss latencies" and it encompasses both > hits and misses, I would think that's a bit paradoxical. Do you agree there or > do you think "miss latencies" fundamentally implies hit latencies as well? > > (As far as tracking miss latencies based off machine type, thanks for the tip. > In the short term, since I just care about L1 hits/misses, I think I'll be > able to > just say "if miss_latency > L1_latency" in my local tree) > > On Wed, Apr 20, 2011 at 11:37 PM, Beckmann, Brad > <brad.beckm...@amd.com>wrote: > > > 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 > > > > > > -- > - 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
