畢業論文編寫筆記


讀論文要點:說了什么,沒說什么,背景,論文之間的關系。

背景(buffer-on-board)

現在的內存系統依然和15年前的一樣,15年前CPU和內存時鍾的差距還不明顯,但現在這種差距導致內存系統無法滿足應用程序和系統對容量和帶寬的需求。

妨礙內存系統改變的因素有多個。內存的利潤相對要小,所以很少有制造商願意冒這個風險;內存系統的改變需要系統的其它部分給予相應的支持,如改變尺寸大小和引腳就需要主板,CPU和芯片組的支持;消費者一般沒有意識到內存系統的重要性,價格的增加並不能讓他們覺得有好處;消費者更喜歡選擇便宜的內存系統。

為了支持一定程度的內存系統定制和擴展,商用DRAM內存以印刷線路板的形式購買(被叫做雙線內存模型DIMM),一般直接插在主板的插槽上,這種物理連接非常適合於低速(<100MHZ)的電信號,但是隨着內存時鍾的增加,這種方式就不太理想了。這種物理連接的信號匯集極大的阻礙了內存時鍾的增加。情況會更嚴重當更多的DIMM被放置在同一個通道上,這種,如下圖所示,越多的DIMM會使得更難判斷在bus中的值。

所以制造商要增加內存時鍾,就必須減少一個通道DIMM的個數來避免信號匯集帶來的問題。這就限制了在一個系統中內存的容量,例如,原來標准的DDR SDRAM,一個通道支持四個DIMM,然后DDR2只有兩個,DDR3只允許一個。雖然通道支持更高容量的DIMM,但是由於DRAM單元大小和每GB價格的限制,DIMM容量增加的速度還是比較緩慢。

基於上面的問題,FB-DIMM內存系統被提出。每個FB-DIMM使用標准的DDRx DRAM設備和AMD(the advanced memory buffer),AMD允許每個內存通道通過解釋一個新的包協議和發送DRAM特定命令給DRAM設備來操作bus。但是,在每個AMD中的高速I/O會導致無法接受的熱量和能量損耗。AMD本身也導致了FB-DIMM比普通的DIMM要貴些。這些問題最終導致FB-DIMM這個標准失敗。

為了解決內存系統容量和帶寬的問題,Intel,AMD和IBM提出了新的架構,盡管和FB-DIMM類似,但是一個根本性的改變是:不是每個DIMM配一個AMD,而是每個通道配一個AMD,這樣就運行新的架構使用已經存在的便宜的DIMM。

buffer-on-board內存系統已經在一些高端的服務器上實現了,但這些實現在一些細節上有很大的不同。本論文的貢獻是探索新的設計來優化相關資源的使用和提供性能。包括對各種類型DRAM的總線配置和合適的隊列深度來達到DRAM的最高效率,地址和通道映射來解決資源沖突。

現在解決一個通道速度和容量的問題通常是使用Ganged rank和Unganged ranks,也就是增加數據總線的寬度,如下圖所示:

 

spec2006(Analysis of Redundancy and Application Balance in the SPEC CPU2006 Benchmark Suite)

簡介

裝載自:http://blog.csdn.net/wyj7260/article/category/1301132

以下表格為spec2006的簡單介紹,分別benchmark的語言,benchmark指令數(單位billion),benchmark指令中,分支執行,load,store指令比例(所占百分比)

 

Name – Language Inst. Count(Billion) Branches % Loads % Stores %
CINT 2006
400.perlbench –C 2,378 20.96 27.99  16.45
401.bzip2 – C 2,472 15.97 36.93  12.98
403.gcc – C 1,064 21.96 26.52  16.01 
429.mcf –C 327 21.17 37.99  10.55 
445.gobmk –C 1,603 19.51 29.72  15.25 
456.hmmer –C 3,363 7.08 47.36  17.68 
458.sjeng –C 2,383 21.38 27.60  14.61 
462.libquantum-C   3,555 14.8 33.57  10.72 
464.h264ref- C   3,731 7.24 41.76  13.14 
471.omnetpp- C++  687 20.33 34.71  20.18 
473.astar- C++  1,200 15.57 40.34  13.75 
483.xalancbmk- C++  1,184 25.84 33.96  10.31 
CFP 2006
410.bwaves – Fortran  1,178 0.68 56.14  8.08 
416.gamess – Fortran  5,189 7.45 45.87  12.98 
433.milc – C  937 1.51 40.15  11.79 
434.zeusmp–C,Fortran  1,566 4.05 36.22  11.98 
435.gromacs-C, Fortran 1,958 3.14 37.35  17.31 
436.cactusADM-C, Fortran  1,376 0.22 52.62  13.49 
437.leslie3d – Fortran  1,213 3.06 52.30  9.83 
444.namd – C++  2,483 4.28 35.43  8.83 
447.dealII – C++  2,323 15.99 42.57  13.41 
450.soplex – C++  703 16.07 39.05  7.74 
453.povray – C++  940 13.23 35.44  16.11 
454.calculix –C, Fortran  3,041 4.11 40.14  9.95 
459.GemsFDTD – Fortran  1,420 2.4 54.16  9.67 
465.tonto – Fortran  2,932 4.79 44.76  12.84 
470.lbm – C  1,500 0.79 38.16  11.53 
481.wrf - C, Fortran  1,684 5.19 49.70  9.42 
482.sphinx3 – C  2,472 9.95 35.07  5.58 

 

參考文獻:

Phansalkar A, Joshi A, John L K. Analysis of redundancy and application balance in the spec cpu2006 benchmark suite[C]//ACM SIGARCH Computer Architecture News. ACM, 2007, 35(2): 412-423.

安裝

安裝地址:http://www.spec.org/cpu2006/Docs/install-guide-unix.html

VMware中先將spec2006.iso掛載到cdrom中,注意不要直接解壓,否則在安裝的時候會出現當前卷設置了noexec標志的錯誤。

1 mount -t iso9660 -o ro,exec /dev/cdrom /mnt

然后安裝到指定的目錄中

1 sh install.sh -d /home/cc/spec

最后運行shrc腳本

1 sh shr

將config目錄下的 Example-linux64-amd64-gcc41.cfg配置文件復制下,命名為gcc41.cfg,由於gem5運行spec需要靜態可執行文件,所以將gcc41.cfg文件修改:

1 COPTIMIZE = -O2
2 CXXOPTIMIZE = -O2
3 FOPTIMIZE = -O2
4 改為
5 COPTIMIZE = -O2 -static
6 CXXOPTIMIZE = -O2 -static
7 FOPTIMIZE = -O2 -static

編譯其中的一個benchmark:

1 runspec --config=gcc41.cfg --action=build --tune=base perlbench 

安裝nvsim

NVSim 是一款對PCM、STT-RAM等新興器材進行模擬的一個模擬器,是由賓夕法尼亞大學開發的,現在處於初期階段,wiki  http://nvsim.org/wiki/index.php?title=Main_Page 

下載方式

1)申請一個bitbucket的帳號 https://bitbucket.org/ 

2)向czx102@cse.psu.edu 發一封郵件,告訴他們你的bitbucket帳號,他們會把你的帳號授權

3)在本地機器上使用 hg clone https://你的帳號@bitbucket.org/nvsim/nvsim 來獲取相關源代碼

我申請的賬號是cc1989,現在已經授權了,可以直接下載源代碼。

GEM5

架構圖:

安裝

1、編譯之前,首先安裝庫文件:

以ubuntu1201系統為例,安裝庫文件如下:

$:sudo apt-get install mercurial scons swig gcc m4 python python-dev libgoogle-perftools-dev g++

2、然后下載gem5源碼:

$: hg clone http://repo.gem5.org/gem5

3、編譯gem5的各個架構:

在根目錄下運行:$:scons build/X86/gem5.opt

可能包zlib庫不存在,安裝zlib1g-dev就行,安裝命令:sudo apt-get install zlib1g-dev。

4、運行測試程序:

$: cd ~/gem5      //進入gem5源碼根目錄

$:build/X86/gem5.opt configs/example/se.py -c tests/test-progs/hello/bin/x86/linux/hello 

將spec cpu2006集成到gem5中http://daystrom.m5sim.org/SPEC_CPU2006_benchmarks

運行多個負載:

build/X86/gem5.opt configs/example/se.py --cmd="tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello" --caches --l1d_size=1kB --l1i_size=1kB --l2cache --l2_size=1kB  --mem-size=4096MB  --mem-type=dramsim2 --cpu-type=timing -n 2 > out

集成DRAMSIM2

1. Download DRAMSim2
  1.1 Go to ext/dramsim2 (this directory)
  1.2 Clone DRAMSim2: git clone git://github.com/dramninjasUMD/DRAMSim2.git

2. Compile gem5
  2.1 Business as usual

3. Run gem5 with DRAMSim2
  3.1 Use --mem-type=dramsim2 and set the device and system configuration

  $: build/X86/gem5.opt configs/example/se.py -c tests/test-progs/hello/bin/x86/linux/hello --caches --l1d_size=64kB --l1i_size=64kB --l2cache --l2_size=4MB  --cpu-clock=2.4GHz --sys-clock=1.4GHz --mem-size=4096MB  --mem-type=dramsim2 --ruby --cpu-type=timing  

--cpu-clock設置操作系統時鍾頻率,--sys-clock設置內存的時鍾頻率,--ruby設置cache架構,如果要使用cache的一些協議可以用這個選項。另外改變DRAM設備的頻率會有影響,改變--sys-clock沒有影響,所以可以不要--sys-clock這個參數。--l1d_size=64kB --l1i_size=64kB設置一級cache的大小,默認是32kB。

GEM5運行SPEC2006

運行bzip2

$:build/X86/gem5.opt configs/example/se.py -c ../install_cpu2006/benchspec/CPU2006/401.bzip2/exe/bzip2_base.gcc41-64bit -o ../install_cpu2006/benchspec/CPU2006/401.bzip2/data/test/input/dryer.jpg -n 4 --caches --l2cache --l2_size=3MB --mem-size=4096MB -m 10000000 --mem-type=dramsim2 --cpu-type=timing  --cpu-clock=2.4GHz --ruby 

注意要加--cpu-type,否則以默認的一個周期一個命令的方式執行。--ruby一定是要的。

多個核運行:

build/X86/gem5.opt configs/example/se.py --cmd="../spec/benchspec/CPU2006/401.bzip2/exe/bzip2_base.gcc41-64bit;../spec/benchspec/CPU2006/401.bzip2/exe/bzip2_base.gcc41-64bit;../spec/benchspec/CPU2006/401.bzip2/exe/bzip2_base.gcc41-64bit" --options="../spec/benchspec/CPU2006/401.bzip2/data/test/input/dryer.jpg;../spec/benchspec/CPU2006/401.bzip2/data/test/input/dryer.jpg;../spec/benchspec/CPU2006/401.bzip2/data/test/input/dryer.jpg" --caches --l1d_size=64kB --l1i_size=64kB --l2cache --l2_size=4MB  --mem-size=4096MB  --mem-type=dramsim2 --cpu-type=timing -n 3 > out

GEM5 CPU模型

文檔地址:http://www.m5sim.org/SimpleCPU

內存系統綜述(Memory Scaling --A Systems Architecture Perspective)

最近內存系統要解決的問題:更多容量,帶寬,能耗以及性能的可預測性。主要的途徑:建立新的DRAM架構(更好的與其它系統連接),采用新內存技術的和利用多種不同的技術來設計新的系統,對應用提供可預測的性能和QoS(服務質量保證)。

目前有兩個主要的趨勢影響內存系統,第一個是已經有很好基礎的基於充電的內存技術,例如DRAM和flash內存,這類技術改進起來很困難,如果能改進,一般都能獲得比較理想的容量和能耗;第二個是一些新內存技術的出現,例如相變存儲(PCM),自旋轉移矩磁存儲(STT-MRAM),這些技術通常由更好的擴展性,延遲與帶寬和DRAM接近,並且是非易失性的,通常它們可以作為DRAM內存系統的一種輔助。

現在設計內存需要考慮的三個方向:(1)克服DRAM的擴展缺陷;(2)使用新的內存技術;(3)設計的內存系統能提供軟件性能和QoS的預測。

新DRAM架構

DRAM被選中作為內存的理由是它的低延遲和廉價,所以一般擴展DRAM都是縮小DRAM單元的尺寸來完成,但是隨着單元尺寸的減少,工藝成本會更加的大,單元漏電更為的嚴重,需要更高的刷新頻率。下面是幾個關鍵新的解決思路:

(1)降低刷新對能耗,性能,QoS和密度擴展的影響。

(2)提升DRAM的並行度/帶寬,延遲,和能耗效率。

(3)改善DRAM單元在更小尺寸下的可靠性。

(4)減少不必要的浪費,由於內存的粗粒度管理,導致很多讀寫數據都是沒用的。

(5)減少數據在DRAM與處理器之間的移動。

下面是針對上面思路的一些具體例子:

降低刷新影響

隨着DRAM容量的增加,假如保持刷新周期不變的話(假設64ms),那么刷新的頻率必然提高(即每次刷新的時間間隔縮短),刷新消耗的時間和能量也會增加。其實有很多行是沒必要64ms就刷新一次的,可能256ms才需要刷新一次,根據這個特性,一篇論文提出了“Retention-Aware Intelligent DRAM Refresh (RAIDR)”思想,RAIDR的主要思想是根據每行中最差數據保存時間的單元將行划分成多個組,每行的刷新周期根據該行最差數據保存時間的單元來決定,這樣大概減少了75%的刷新操作。這種思路主要基於DRAM中每個單元的保存數據時間不一致性的特性。(是不是還可以進一步的改進?對於剛完成訪問的行可以不用刷新直接跳到下一行進行刷新,這對這一行完成的時間有一定要求,不能太長)

提高DRAM的並行性

 限制DRAM並行性的關鍵因素是bank沖突,最近提出的開發DRAM bank的子矩陣結構,叫做SALP(subarray level paral-lelism),關鍵思想就是訪問相同的bank,不同的子矩陣的兩個相鄰請求可以通過流水線的方式處理。

降低DRAM的延遲和能耗

由於bitline太長的緣故,使得DRAM延遲很大,為了減少這種延遲,通過隔離晶體管將bitline分成兩段(低延遲段和高延遲段),低延遲段采用短的bitline,高延遲段采用高密度bitline。

開發批量數據操作

現在的內存系統浪費了大量的帶寬,延遲來傳輸不必要的數據到cache中。如果批量傳輸的源和目標都在同一個子數組中,可以通過一個特殊的命令,對目標行激活后,將源行的數據直接拷貝的目標行,這樣就節省了內存系統與CPU直接的數據傳輸。

新的內存技術

 新的內存技術包括PCM和STT-MRAM,但它們似乎很難真的完全取代DRAM,原因在於它們相對DRAM並沒有絕對的優勢。如PCM,有更小的尺寸,每個單元能存放多個bit;非易失性,不需要刷新;低功耗。然而另一方面,讀寫延遲和能耗都很大。怎樣利用新內存技術來完全取代DRAM呢?一種可行的方法是重新組織外圍電路使得PCM的性能能與DRAM接近,充分利用它們的非易失性是這個方法的關鍵之一。

我們有理由相信,新的內存技術有機會在系統級方面發揮作用。(1)混合內存系統;(2)非易失性內存系統;(3)內存與存儲系統的結合

混合內存系統

 關鍵問題是怎樣管理數據在不同技術之間的分配和移動來達到最佳的性能。混合內存系統的設計空間很大,存在各種問題,例如哪個作為cache,哪個作為主存?系統的什么組件用來管理數據的分配和移動?不同技術間數據移動的粒度?

例如在DRAM和PCM中的行緩存策略,然而PCM行緩存失效會導致更高的延遲、帶寬和能耗的損失。為此,提出一個策略來避免訪問PCM中的數據頻繁的引起行緩存失效,通過硬件或軟件動態的記錄哪些數據頻繁的引起PCM行緩存失效,並將這些數據遷移到DRAM中,將頻繁命中行緩存的數據存入PCM中。還有就是PCM的寫延遲/功耗要高於讀延遲/功耗,基於這個考慮應該將寫頁面的數據存入DRAM中。

是不是可以通過仿真DRAM+STT-RAM的混合內存系統來實現上述的某一策略,再添加一層混合內存控制器層?

預測應用性能和QoS

預測應用程序的性能可以通過統計應用程序的請求服務速率來判斷。盡量減少各個應用、線程之間的干擾。

減少讀寫轉換的延遲

虛擬寫隊列(The_Virtual_Write_Queue_Coordinating_DRAM_and_Last-Level Cache Policies)

介紹

從DRR到DRR3,IO頻率在增加,但是讀寫轉換延遲幾乎保持不變,這使得讀寫延遲需要花費更多的時鍾周期,使得bus的利用率下降,從下圖就可以看出這一趨勢。
每代DDR的晶體管數量都會翻倍,但是每代CPU中核的數量卻超過兩倍,導致每個核可利用的cache大小在減小,進而導致更高的不命中率和更高的內存帶寬要求。所以多內核架構中,主存不僅要有更高的帶寬,而且還要有更高的總線利用率。通常,在處理器中一般就一到兩個內存控制器,導致多個核共用一個內存控制器,這樣一個內存控制器就要同時服務於多個不同的工作流,在這種情況下,空間訪問的局部性會很差。

基於上面兩個問題,在過去主要的解決辦法是通過重排內存控制器收到的請求。論文《Fair Queuing Memory Systems》利用公平隊列來達到公平性和吞吐量的提升;論文《Parallelism-Aware Batch Scheduling》將來自不同核的請求進行分組,然后批量的發送給控制器。這些技術在提供讀性能有很大的幫助,但不能直接解決寫性能的問題。《Eager writeback》解決了一些寫性能的問題,但這種方法內存控制器與last cache的交互很少。

如果有更大的寫隊列,那么內存控制器就可以更高效的決定命令的優先級和有效的調度寫請求到內存總線。關鍵問題是怎樣增大寫隊列,這篇論文采用了一種叫做“Virtual Write Queue”的技術,利用last cache的部分容量來擴展寫隊列的容量。基於這個模型,提出的“Scheduled Writebacks”方法能有效的利用內存帶寬,它能導致更長的寫發射,從而減少總線在讀寫轉換的時間(tWRT),減少讀操作沖突。

 內存系統特性

Bus turnaround penalty

寫后讀相對寫后寫來說增加了很大的開銷,主要由於tWRT的限制。

所以內存調度的效率在混合讀寫請求的情況下被嚴重地影響。由於tWRT的限制,導致這種情況是很難避免的,但是如果在改變訪存操作類型之前盡量增加相同類型操作的個數,總線利用率會有明顯的提高。

page模式

每個DRAM設備對每個命令都會操作內部的一個大小為kbit級別的頁(也叫做row),隨機的訪問DRAM設備,會導致每個命令都會操作一個不同的頁到行緩存中。如果后續訪問的命令都在同一個頁中,那么時間和能耗能都有很大的減少,從下面的表中可以清楚的看到。

隨着寫隊列項的增加,在隊列中的請求中寫同一頁次數的情況如下:

在實際的隊列大小,例如32,基本沒有利用到頁模式,從圖中看出訪問每頁的次數為1。也就是說大部分的空間局部性都包含在了各級的cache中,但是現在的cache架構並不給內存控制器查看局部性,增加內存控制器中寫隊列的容量可以提高空間局部性的可視性和更好的利用頁模式,盡管不切實際。

Bursty行為

當cache行不被命中時,就需要用新的cache行替換舊的cache行,如果舊的cache被修改了,那么就必要存在讀寫命令的混合。下面是每個訪存操作的時間分布:

從圖中可以看出,有20-24%的訪存操作花費的時間少於10個時鍾周期,還有20%的花費200-250個時鍾周期。如果寫操作能更早的被執行,那么后面讀操作就能花費更少的時間。

cache與內存合作的系統

上面的三個內存問題都能解決,如果內存控制器能看到更多的寫操作。典型的內存控制器中大概包含10個入隊的寫操作。隊列大小意味着面積和能耗,所以隊列尺寸對應整個內存系統性能來說是一個很重要的參數。我們的方法是將最后一層的cache的LRU部分作為寫隊列,並將其稱做Virtual Write Queue。通過這個技術可以解決前面提到的三個問題:

Bus turnaround penalty避免

通過Scheduled writeback策略,我們可以有效的發送正在等待的寫操作,最小化讀寫操作的混合。

獲得更多的頁模式機會

通過直接查詢cache的LRU部分,使得更多的寫操作被執行。

Burst leveling

Virtual Write Queue的容量大概是標准內存控制器寫隊列的1000倍。

Scheduled Writeback

傳統的cache writeback策略是當cache滿的時候取代一個LRU cache行,我們叫它forced writeback。這種策略有兩個問題,一個是:寫操作只在cache行滿的時候發送給內存控制器,以至於空閑的DRAM周期內並不能被寫操作填滿。前面提到的“Eager Writeback”則是當檢測到內存控制器空閑的時候(一個空的寫隊列被檢測到)cache行被發送給內存控制器;另一個是:處理寫操作到DRAM資源的映射。由於控制器能獲取每個DRAM的狀態,所以它能有效的選擇哪個writeback可以被執行,在“Eager Writeback”中,這個選擇由cache來做,而不管DRAM的調度。我們介紹的Scheduled Writeback解決了這個問題,即內存控制器能指揮cache傳輸行到特定的DRAM資源。

如上圖所示,相比傳統的結構,在cache和物理寫隊列中增加了一個結構叫Cache Cleaner。這個結構從cache到物理隊列中精心執行Scheduled Writebacks。

高層次的描述

在穩定狀態下,物理寫隊列滿,內存系統各個資源都被充分利用。寫的優先級由隊列滿的狀態決定,當物理隊列減少時,Cache Cleaner會到Virtual Write Queue搜索寫操作。選擇寫操作有兩個方法:一是如果內存控制器正在向某個rank寫數據,那么優先選擇寫到這個rank的寫操作;而是如果內存控制器沒有在操作,選擇這樣的寫操作,該寫操作寫到的rank是在當前物理寫隊列中操作rank數少的rank。Cache Cleaner盡量從cache中獲取同一個頁的寫操作,這個實現是通過cache sets來完成的。

物理寫隊列分配

 本論文主要的難點就是解決讀寫轉換的問題,除此之外還有共享bus的rank之間的轉換。為了達到更好的效果,DRAM bank必須被管理以避免各種讀寫操作映射到同一bank的不同頁,這樣就能最大限度的保證持續發射更多的讀命令或者寫命令到rank,而不會引起bank沖突。Physical Write Queue主要解決的是持續發射寫命令的問題。

Virtual Write Queue的一個關鍵問題是它是一個兩個級別的設計,當Physical Write Queue寫隊列中的寫被執行時,Scheduled Writebacks必須協調這一動作從Virtual Write Queue中發送寫命令給Physical Write Queue。

The Cache Cleaner

核心思想是:Cache Cleaner使用一個叫SSV(The Set State Vector)的結構來記錄cache中每個組是否包含了急需要寫回的臟數據,每個組對應SSV中的一個bit(如下圖a),所以增加的硬件開銷很小。為了能快速定位每個組臟數據塊所在的組,SSV組織成下圖b,其中每項對應一個rank,一個bank是否有臟數據在cache行中的某個組中。通過批量調度這些臟數據提前寫回到內存中,從而減少讀寫轉化直接的切換時間。主要考慮盡量多的批量寫到內存中,而且盡量使寫發送在讀之前,即寫優先。主要考慮了tWRT問題,對於tRRD,tFAW沒有考慮,tWR也沒考慮。

 

分布讀(Staged Reads : Mitigating the Impact of DRAM Writes on DRAM Reads )

當內存對一些bank進行寫時,對空閑的bank進行cacheline預讀取操作,將讀取的cacheline緩存到寄存器中,當從寫經過tWRT后可以立即發送數據到bus中,從而減少延遲。(未考慮tFAW等限制)

Improving Writeback Efficiency with Decoupled Last-Write Prediction

也是想辦法解決寫的行bit率和bank並行問題,與虛擬寫隊列不同,它不依賴於LLC的替換策略,選取last-write cacheline通過一種預測算法。這種預測算法基於這樣的事實:如果一個核的pc1寫了一個cacheline,后面另一個核的pc2寫了同樣的一個cacheline,那么在只有pc1寫的cacheline就很可能不是last-write cacheline;如果一個核的pc1寫了一個cacheline后,這個cacheline被替換出去了,那么這個pc1寫的cacheline很有可能是last-write cacheline。

減少刷新消耗

數據在cell中駐留時間的實驗研究(An experimental study of data retention behavior in modern dram devices: Implications for retention time profiling mechanisms)

RAIDR: Retention-Aware Intelligent DRAM Refresh

Techniques to mitigate refresh penalties in high density memory

Coordinated Refresh Energy Efficient Techniques for DRAM Refresh Scheduling

Improving DRAM Performance by Parallelizing Refreshes with Accesses

提出了每bank的動態刷新架構,選擇刷新idle的bank,這和傳統的round-robin刷新是不同的;提出了利用bank內部的子數組結構實現刷新與訪問的並行。可不可以動態選擇刷新idle的rank呢?

性能優化

開發子矩陣的並行(A case for exploiting subarray-level parallelism (SALP) in DRAM)

Tiered-latency dram: A low latency and low cost dram architecture

RowClone: Fast and Efficient In-DRAM Copy and Initialization of Bulk Data

Skinflint DRAM System: Minimizing DRAM Chip Writes for Low Power

通過在cache行中標記哪些字節是修改的,然后寫回的時候cache行中沒有被修改的字節對應的芯片不被選中,從而節省能耗。

服務質量和公平性

Minimalist open-page: a DRAM page-mode scheduling policy for the many-core era

這種將連續的讀或寫到同一行會導致對不同線程產生不公平,甚至會導致有的線程飢餓。所以在dramsim2的配置文件中有個配置項TOTAL_ROW_ACCESSES,它被設置為4,也就是說如果連續訪問同一行的次數大於4,這行就會被強制關閉。為了減少這種消耗並增加bank的並行性,開發了一種地址映射架構:

這樣使得對同一行的連續hit數不會超過四,同時增加了bank的並行性。

論文還對prefetch和普通命令設置了優先級,普通命令優先級比prefetch優先級高,普通命令優先級通過每個core中的Miss Status Holding Registers的值來計算,如果Registers少,說明miss少,那么每個內存的命令都是對性能有很大影響的,所有優先級高,反之優先級低。prefetch的優先級由預取元數據信息來決定。

延遲敏感和帶寬敏感的線程優先級不同。

Priority Based Fair Scheduling

線程分為延遲敏感和帶寬敏感的,通過對線程進行優先級的划分,延遲敏感的優先級設置高優先級,帶寬敏感的優先級設置低優先級,並且隨着時間動態調整線程優先級。

Reducing Memory Interference in Multicore Systems via Application-Aware Memory Channel Partitioning

 統計內存敏感、內存密集的但row bit不高和內存密集的但row bit高的應用,對這三組應用分配對應的通道組,從而減少這三類應用直接的干涉。分配通過是通過修改操作系統的頁分配算法實現的,統計row bit和llc不命中率是通過硬件實現。

Parallelism-Aware Batch Scheduling

最大化row hit率和bank並行性。在batch中,每個bank的請求數不能超過Marking-Cap,這樣其實保證了公平性,不會有請求會飢餓;然后在batch中根據row buffer和thread排名來調度。對於多個rank的情況呢?

思考

1、Virtual Write Queue和DRAM-Aware LLC Writeback提升的是高的行緩存命中率,Staged Reads減少的是寫到讀的延遲,是否考慮過讀到寫的延遲呢?是否考慮過同一rank的不同bank的連續讀或寫。

讀到寫的延遲優化主要是盡量將連續的寫發送到相同的行或者同一rank的不同bank。

寫到讀的延遲可以通過預讀來盡量減少。

減少連續寫的時間:主要是盡可能的流水化連續寫,也就是盡量安排寫到同一個rank的不同bank或同一bank的同一行。

同一rank的不同bank會受到tFAW(在tFAW時間窗口內最多只能有4個bank處於行激活狀態,處於能耗的考慮)的限制。

這種將連續的讀或寫到同一行會導致對不同線程產生不公平,甚至會導致有的線程飢餓。所以在dramsim2的配置文件中有個配置項TOTAL_ROW_ACCESSES,它被設置為4,也就是說如果連續訪問同一行的次數大於4,這行就會被強制關閉。

虛擬寫隊列用的是cache的LRU來選擇臟塊,可不可以用其它的cache替換策略來做?

是否可以通過在每個cacheline上加上一個核的標記,通過這個核的標記來調度從而實現row kit率,bank並行率,公平性的提升,並且減少不同應用之間的干預。

可否根據row hit率來優先調度row hit高的應用,這樣一個很明顯的特性就是低row hit的應用被延遲了。所以要綜合row hit(一般限制在4左右)和bank的並行來調度。

很多算法都沒有考慮過rank的情況,都是針對一個rank進行優化。

預選題目

提升內存敏感性應用性能的內存調度策略研究 : 優先調度內存敏感應用,在批量寫時預讀內存敏感應用的數據。基於這樣的事實:提升系統整體性能主要取決於內存敏感性應用性能提升。

 

國內外研究機構

http://soc.fudan.edu.cn/vip/projects/gradproj/wiki/%E8%BE%83%E4%B8%BA%E6%B4%BB%E8%B7%83%E4%B8%8E%E6%9B%BE%E7%BB%8F%E8%BE%83%E4%B8%BA%E6%B4%BB%E8%B7%83%E7%9A%84%E7%9B%B8%E5%85%B3%E7%A0%94%E7%A9%B6%E5%9B%A2%E9%98%9F


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM