RSVM: a Region-based Software Virtual Memory for GPU
Parallel Architectures and Compilation Techniques (PACT), 2013 22nd International Conference on
Fast, Multicore-Scalable, Low-Fragmentation Memory Allocation through Large Virtual Memory and Global Data Structures
Main-memory hash joins on multi-core CPUs: Tuning to the underlying hardware
ISCA’13 Tel-Aviv, Israel
Copyright 2013 ACM 978-1-4503-2079-5/13/06... $15.00
Page Replication
DMR3D: Dynamic Memory Relocation in 3D Multicore Systems
http://ieeexplore.ieee.org/document/6560750/
https://www.youtube.com/watch?v=Dml54J3Kwm4
Dynamic Memory Relocation 我们来想一下这个情况：MySQL的线程分为两种，用户线程（SQL执行线程）和内部线程（内部功能，如：flush，io，master等）。对于用户线程来说随机性相当的强，但对于内部线程来说他们的行为以及所要访问的内存区域其实是相对固定且可以预测的。如果能对于这把这部分内存集中到这些内存线程所在的core上的时候，就能减少大量
Remote Access，潜在的提升例如Page Flush，Purge等功能的吞吐量，甚至可以提高MySQL Crash后Recovery的速度（由于recovery是单线程）。 那是否能在Interleave模式下，把那些明显应该聚集在一个CPU上的内存集中在一起呢？ 很可惜，Dynamic Memory Relocation这种技术目前只停留在理论和实验阶段。我们来看下难点：要做到按照线程的行为动态的调整page在memory的分布，就势必需要做线程和内存的实时监控（profile）。对于Memory Access这种非常异常频繁的底层操作来说增加profile入口的性能损耗是极大的。在 关于CPU Cache程序应该知道的那些事的评论中我也提到过，这个道理和为什么Linux没有全局监控CPU L1/L2 Cache命中率工具的原因是一样的。当然优化不会就此停步。上文提到的Carrefour算法和Linux社区的Auto NUMA patch都是积极的尝试。什么时候内存profile出现硬件级别，类似于CPU中 PMU 的功能时，动态内存规划就会展现很大的价值，甚至会作为Linux Kernel的一个内部功能来实现。到那时我们再回过头来审视这个方案的实际价值。
Page Replication 再来看一下这些情况：一些动态加载的库，把他们放在任何一个线程所在的CPU都会导致其他CPU上线程的执行效率下降。而这些共享数据往往读写比非常高，如果能把这些数据的副本在每个Memory Zone内都放置一份，理论上会带来较大的性能提升，同时也减少在inter-connect上出现的瓶颈。实时上，仍然是上文提到的Carrefour也做了这样的尝试。由于缺乏硬件级别（如MESI协议的硬件支持）和操作系统原生级别的支持，Page Replication在数据一致性上维护的成本显得比他带来的提升更多。因此这种尝试也仅仅停留在理论阶段。当然，如果能得到底层的大力支持，相信这个方案还是有极大的实际价值的。
發表文章
沒有留言:
張貼留言