毕业论文编写笔记
读论文要点：说了什么，没说什么，背景，论文之间的关系。
背景（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
