From c01b9cd62b981584612b44cefa6d0c94493ddf57 Mon Sep 17 00:00:00 2001 From: Arthur Perais Date: Fri, 4 Jun 2021 09:46:14 +0200 Subject: [PATCH] mem: Fix bandwidth-delay calculation in AMPM prefetcher MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The AMPM paper (https://www.jilp.org/vol13/v13paper3.pdf) defines the bandwidth-delay calculation as : Mbandwidth= (Nrequests/Tepoch)×Tlatency In the code, Tepoch and Tlatency are in ticks (which is okay), but Tepoch is converted from Cycles (256K) to Ticks using the clockEdge(Cycle c) function, which is incorrect as it yields currentTick + c * clockPeriod() instead of just c * clockPeriod(). In other words, the divider keeps increasing as time advances. This patch substitutes clockEdge() with cyclesToTicks() to keep the epoch length (Tepoch) constant throughout simulation. Change-Id: I69dee29892fa4b9eb8de8715fd72a535e122687f Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46479 Reviewed-by: Nathanael Premillieu Reviewed-by: Daniel Carvalho Maintainer: Jason Lowe-Power Tested-by: kokoro --- src/mem/cache/prefetch/access_map_pattern_matching.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mem/cache/prefetch/access_map_pattern_matching.cc b/src/mem/cache/prefetch/access_map_pattern_matching.cc index 6a632e002f..89418a0270 100644 --- a/src/mem/cache/prefetch/access_map_pattern_matching.cc +++ b/src/mem/cache/prefetch/access_map_pattern_matching.cc @@ -80,7 +80,7 @@ AccessMapPatternMatching::processEpochEvent() double num_requests = (double) (numRawCacheMisses - numGoodPrefetches + numTotalPrefetches); double memory_bandwidth = num_requests * offChipMemoryLatency / - clockEdge(epochCycles); + cyclesToTicks(epochCycles); if (prefetch_coverage > highCoverageThreshold && (prefetch_accuracy > highAccuracyThreshold ||