AIFM – High-Performance, Application-Integrated Far Memory

AIFM 提出一种在用户态完成 swap 的方案,相比传统的内核态(虚拟内存)的方案,实现了:
  1. 更低的延迟:相比 fastswap,有6倍吞吐的提升
  2. 更高的灵活性:用户可以显式指定一块内存是local还是far(指向 remote memory)
0

1. 一些背景

1) OS swapping and far memory
之前对 swap 以及 far memory 相关的研究,大多都是在内核态的,由于内核态的 swap 都是 4k 粒度的,对于一些随机大量的小object场景,会带来很多性能问题
另一方面,如果你要依赖一些应用的信息(比如访存的行为、访存策略、内存热点)去做性能优化,这也是做不到的(madvise有一些近似的功能,但是不够)
为此,AIFM 提出了一种object级别的,可以访问远端内存的,类似于c++弱指针的一种新型指针
2)Disaggregated and distributed shared memory
当前大多数 Disaggregated memory 相关的实现,都要求数据中心具备高速互联的能力(但是现在很多数据中心其实还不具备这个能力),AFIM 提供了一种软件级的解决方案
另外一个问题是,传统的 far memory 系统里面,一份数据需要被多个 host 共享,这就要解决很复杂的数据一致性问题(同时带来了很大的性能开销)
AIFM 简化了这个问题, far memory 中的数据只属于一个 host

2. 整体架构

AIFM设计的核心思想是使用一个用户态的库(编程语言C++)来实现冷内存的远程存储
整体架构如下:
0
其中,Runtime 就三部分:
  1. 一个 library
  2. 一个轻量级线程,pauseless memory evacuator,定期将不常用的内存 swap 到远端
  3. 一个 Remote Agent,可以实现内存的远程拷贝,并返回指针(极大的提高效率,减少带宽传输)
除此之外,Runtime 使用了 DPDK 技术(a kernel-bypass TCP/IP networking stack)来提高通讯性能,不依赖 rdma
app 运行时的原理图:
0

2.1. Runtime API

AIFM 定义了一套可使用远程内存的数据结构,这些数据结构在使用上,和普通的c++ STL基本上没区别。
比如:std 里的 unordered_map 和 AIFM 里的 RemHashtable
std 的
std::unordered_map<key_t, int> hashtable;
std::array arr;
void print_data(std::vector& request_keys) {
    int sum = 0;
    for (auto key : request_keys) {
        sum += hashtable.at(key);
    }
    std::cout << arr.at(sum) << std::endl;
}
AIFM 的
RemHashtable<key_t, int> hashtable;
RemArray arr;
void print_data(std::vector& request_keys) {
    int sum = 0;
    for (auto key : request_keys) {
        DerefScope s1; // Explained in Section 4.2.2.
        sum += hashtable.at(key, s1);
    }
    DerefScope s2;
    std::cout << arr.at(sum, s2) << std::endl;
}

其原理非常像当年Ray那篇论文:Ray: A Distributed Framework for Emerging AI Applications https://arxiv.org/pdf/1712.05889.pdf
除此之外,对指针的处理是比较复杂的,细节可以看论文

2.2. Runtime 的实现

这里都是在讲 Runtime 怎么实现的了,但是细节有没有讲太多,可以推测一下
2.2.1. Hiding Remote Access Latency
传统的 DSM 系统访问远程内存,是需要陷入到内核态的(上下文切换),这个过程大概500ns,高频访问开销极大
fastswap 解决这个问题的思路是使用 polling,会增加一些额外的计算开销
AIFM 使用异步fetch的机制来解决这个问题
AIFM’s runtime spawns prefetcher threads to pull in objects that it predicts will be dereferenced in the future(论文好像没提怎么做 predict 的?)

2.2.2. Remoteable Memory Layout

xx

2.2.3. Pauseless Memory Evacuator

xx

2.2.4. Concurrent Evacuation Phase

xx

3. 性能评估

0
横轴:单次访存后计算时间,越大表示访存越不频繁
看来经过精准的 prefetch,AIFM 可以做到 ideal 性能。另外高频访存的情况下,不管是 AIFM 还是 fastswap,性能都不怎么样,所以这个技术的使用场景还是有一些限制的
发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注