GEM5: Different cache latency for read and write access 设置不同的读写latency

本文介绍如何在gem5模拟器中为缓存设置不同的读写延迟。通过应用特定补丁,可在gem5中分别指定读取和写入缓存的延迟时间,从而更精细地控制模拟行为。

参考:2072reviews,1809reviews

由于gem5的cache默认读写延迟都是hit_latency,故无法设置不同的延迟,经过摸索,终于找到了read/write latency的修改方法,主要参考上面链接中的patch,将patch中的内容修改到自己的gem5源码中,然后再编译一次即可。

该patch的介绍如下:

This patch allows specifying different cache latency for read and write access. (In the code, the hit_latency parameter is actually the read_latency)

经过咨询该补丁的作者,修改后的hit_latency的含义就是read_latency,write_latency即新增加的参数,可以在caches.py文件中配置。

这样就可以设置cache不同的读写延迟了。

关于diff的代码如下:

diff -r 6a043adb1e8d src/mem/cache/BaseCache.py
--- a/src/mem/cache/BaseCache.py    Thu Jul 11 13:56:05 2013 -0500
+++ b/src/mem/cache/BaseCache.py    Thu Jan 09 10:25:33 2014 +0100
@@ -50,6 +50,7 @@
     assoc = Param.Int("associativity")
     block_size = Param.Int("block size in bytes")
     hit_latency = Param.Cycles("The hit latency for this cache")
+    write_latency = Param.Cycles("The write latency for this cache")
     response_latency = Param.Cycles(
             "Additional cache latency for the return path to core on a miss");
     max_miss_count = Param.Counter(0,
diff -r 6a043adb1e8d src/mem/cache/base.hh
--- a/src/mem/cache/base.hh Thu Jul 11 13:56:05 2013 -0500
+++ b/src/mem/cache/base.hh Thu Jan 09 10:25:33 2014 +0100
@@ -251,6 +251,11 @@
     const Cycles hitLatency;

     /**
+     * The latency of a write in this device.
+     */
+    const Cycles writeLatency;
+
+    /**
      * The latency of sending reponse to its upper level cache/core on a
      * linefill. In most contemporary processors, the return path on a cache
      * miss is much quicker that the hit latency. The responseLatency parameter
diff -r 6a043adb1e8d src/mem/cache/base.cc
--- a/src/mem/cache/base.cc Thu Jul 11 13:56:05 2013 -0500
+++ b/src/mem/cache/base.cc Thu Jan 09 10:25:33 2014 +0100
@@ -73,6 +73,7 @@
                   MSHRQueue_WriteBuffer),
       blkSize(p->block_size),
       hitLatency(p->hit_latency),
+      writeLatency(p->write_latency),
       responseLatency(p->response_latency),
       numTarget(p->tgts_per_mshr),
       forwardSnoops(p->forward_snoops),
diff -r 6a043adb1e8d src/mem/cache/cache_impl.hh
--- a/src/mem/cache/cache_impl.hh   Thu Jul 11 13:56:05 2013 -0500
+++ b/src/mem/cache/cache_impl.hh   Thu Jan 09 10:25:33 2014 +0100
@@ -284,7 +284,16 @@
         uncacheableFlush(pkt);
         blk = NULL;
         lat = hitLatency;
-        return false;
+   // Update latency decided by if it is read or write
+   if(pkt->isWrite()) {
+       lat = writeLatency;
+   }
+   return false;
+    }
+
+    // Update latency decided by if it is read or write
+    if(pkt->isWrite()) {
+   lat = writeLatency;
     }

     int id = pkt->req->hasContextId() ? pkt->req->contextId() : -1;
@@ -928,7 +937,7 @@
                 // from lower level caches/memory to an upper level cache or
                 // the core.
                 completion_time = clockEdge(responseLatency) +
-                    (transfer_offset ? pkt->busLastWordDelay :
+                    writeLatency * clockPeriod() + (transfer_offset ? pkt->busLastWordDelay :
                      pkt->busFirstWordDelay);

                 assert(!target->pkt->req->isUncacheable());
@@ -1255,7 +1264,7 @@
     }

     blk->whenReady = clockEdge() + responseLatency * clockPeriod() +
-        pkt->busLastWordDelay;
+        writeLatency * clockPeriod() + pkt->busLastWordDelay;

     return blk;
 }
diff -r 6a043adb1e8d src/mem/cache/tags/lru.cc
--- a/src/mem/cache/tags/lru.cc Thu Jul 11 13:56:05 2013 -0500
+++ b/src/mem/cache/tags/lru.cc Thu Jan 09 10:25:33 2014 +0100
@@ -125,20 +125,20 @@
     delete [] sets;
 }

+// Modification to take in account the right access latency (read or write)
 LRU::BlkType*
 LRU::accessBlock(Addr addr, Cycles &lat, int master_id)
 {
     Addr tag = extractTag(addr);
     unsigned set = extractSet(addr);
     BlkType *blk = sets[set].findBlk(tag);
-    lat = hitLatency;
     if (blk != NULL) {
         // move this block to head of the MRU list
         sets[set].moveToHead(blk);
         DPRINTF(CacheRepl, "set %x: moving blk %x to MRU\n",
                 set, regenerateBlkAddr(tag, set));
         if (blk->whenReady > curTick()
-            && cache->ticksToCycles(blk->whenReady - curTick()) > hitLatency) {
+            && cache->ticksToCycles(blk->whenReady - curTick()) > lat) {
             lat = cache->ticksToCycles(blk->whenReady - curTick());
         }
         blk->refCount += 1;
### 含义 在 `DBWrapper` 中,`report latency for each error is false` 表明系统不会针对每一个错误单独报告其延迟情况。延迟通常指的是从请求发出到收到响应所花费的时间,在数据库操作里,可能涵盖查询、插入、更新等操作的耗时。当此参数设为 `false` 时,系统不会对每个错误的延迟进行详细记录和上报。 `specific error codes to track for latency are: []` 意味着没有指定要专门跟踪延迟的特定错误代码。一般而言,在数据库操作过程中会出现各种不同的错误代码,每个代码代表不同类型的错误。当指定了特定的错误代码后,系统会着重记录这些错误发生时的延迟情况,而这里空列表表示没有设置需要特别关注的错误代码。 ### 影响 - **监控与分析方面**:由于不报告每个错误的延迟,在监控系统运行状况时,难以精准定位哪些错误会导致较长的延迟,这可能会影响对系统性能瓶颈的分析。例如,在排查数据库性能问题时,无法依据错误延迟数据判断是哪种类型的错误对系统响应时间影响最大。 - **故障排查方面**:缺少特定错误代码的延迟跟踪,在遇到错误时,很难从延迟的角度分析错误的严重性和影响范围。比如,当出现某个特定错误代码的错误时,因为没有该错误延迟的记录,就无法判断该错误是偶尔出现的小问题,还是会导致系统长时间响应缓慢的严重问题。 - **优化策略制定方面**:由于缺乏错误延迟的详细信息,在制定系统优化策略时,难以有针对性地对导致延迟的错误进行优化。例如,无法确定对哪些错误类型进行处理可以最有效地减少系统的整体延迟。 ```python # 假设这是一个简单的DBWrapper类的部分代码示例 class DBWrapper: def __init__(self): self.report_latency_for_each_error = False self.specific_error_codes_to_track = [] def execute_query(self, query): try: # 模拟执行查询操作 pass except Exception as e: error_code = 1 # 模拟错误代码 if self.report_latency_for_each_error and error_code in self.specific_error_codes_to_track: # 记录延迟等操作 pass ```
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值