Introduction to Compilers and Language Design

这本书又更新了. 是个重新学习编译技术的好时机.

我设计ChocoPy的时候觉得自己挺无力的,

  1. Semantic和LLVM部分对Symbol的定义重复。
  2. 对于Semantic的设计参考Java版chocopy过多,应该多搞点enum而不是虚空基类。(但是为了给小朋友做还是需要区分一下难度,如果自己写应该搞C++优化的类内存排布的。3倒比较偏正常的C++程序一点。
  3. 我觉得我没有很好的讲清楚LLVM和后端mapping的关系,不止寄存器分配,如果类能设计的更好一点就不会仅仅+字符串了,总之就是后端抽象的还不够。

An Empirical Study of the Effect of Source-Level Loop Transformations on Compiler Stability @OOPSLA18

定义了一个loop optimization stability,用于查看在优化后两个相同语义的代码能获得稳定的相同输出。通过先loop extract出for循环按RO/WAR&WO/RAW分类。loop mutate benchmark,metric定义了行为相似度(代码静态分析和动态PMU行为),也定义了不同编译器之间的稳定性,(所谓的z一致性)

用处是可以指导编译器语义修改、可以增加loop heuristics来让编译器没有做向量化的transform去做向量化。

RecSSD: Near Data processsing

This paper is an implementation of near-data processing data placement for recommendation inference. Normally, the operation by embedding table operation is ~10 GB of storage, irregular Access and Low compute intensity.

2 Fully connected layer with non-conformed-sized embedding table. The embedding table is organized such that each row is a unique embedding vector, typically including 16, 32, or 64 learned features (i.e., the number of columns in the table). For each inference, a set of embedding vectors, specified by a set of identifiers (e.g. multi-hot coded classification inputs), are aggregated together. Common operations for aggregating embedding vectors together include summation, averaging, concatenation, and matrix multiplication [30, 445]; Figure 1 shows an example of using summation. Inference requests are often processed in batches to share the control overhead and make better use of computational resources. In addition, the model usually contains many embedding tables. Currently, production-scale data centers store embedding tables in dynamic random access memory, while the central processor performs embedding table operations and optimizations, such as vectorization instructions and software prefetching.

Embedding-Domain models include DLRM-RMC1,2,3, their observation is the hot memory hit gets up drastically for several pages. This requires a real-world computation to have a software-defined allocation and prefetching technique and vectorization.

Implementation

Their solution is on an OpenSSD over micro UNVMe stack (which can simply be replaced with SmartSSD.)

caching requires both side DRAM caching, and the multithread I/O queue are fused with SSD






Performance

ctFS: Replacing File Indexing with HW Memory Translation t/ Contiguous File Allocation @FAST22

最近正好也在看CMU的745,又发现了一坨来自SNU的韩语讲解,最近又需要RIIR kernel memory和FS部分的代码,我感觉是个好好重新学习文件系统的好机会。(以及感觉PM的很多工作可以直接Migrate 到CXL上来(似乎MMU和DAX映射可以完全一模一样),看看有没有什么东西可以挖。

Background

indexing在splitFS和ext4-DAX的时间画的很多,尤其是SWE/Append。

ext4-DAX需要先得到index nodes(directory extent tree)再得到leaf nodes,在最后的extent index上才会做virtual address的MMU。这对PM来说是比较慢的过程

Insight

观察1: 我们可以linear mapping file,把file当byte addressable的inode,这样对file的读取只需要 start+offset(这样拿到MMU后的隔离似乎有点问题)
观察2:前半部分的directory extent tree(似乎是个红黑树)可以放在PM的MMU上来执行。

我们发现File 被实际映射到PM物理介质上的过程和在PM上Page Walk的过程类似。而且我们对pagetable的每4k做一次partition,可以完整的完成对文件的抽象。


在一个非flat的文件系统中,文件分为多层,但是每一层放稍微比上一层大的文件会产生极大的浪费,所以我们仍然需要维护partition头,其包含superblock, 和下一层的inode bitmap。


对于migration,我们通过一个系统调用来保证continuous memory和REDO LOG 保证的crash consistency。

可以显见在128MB aligh对齐64个PMD entries的时候会比32k PT entries快。

一个特殊情况是atomic write。其实就是要写的先写在后面再copy on write pswap回来。

Reference

  1. https://www.youtube.com/watch?v=pT46-RYOsmw&t=309s

Pointer Chase

远端(异构)内存+内存随机workload会产生交替执行;这样会导致数据依赖(pointer-chasing现象)和加载到缓存里的数据重用率不高。为了具体分析这两个因素对系统性能的影响,可以尝试分别针对L1 cache、L2 Cache、L3 cache、本地内存以及远端(异构)内存的顺序读。

Pointer Chasing 是一个可以被利用的technique来得到远端内存的下一个block或track free block。 inode就是最好的例子。

应用

  1. 最近多次在optane memory的RE writeup 中找到,说明MMU的信息可以通过ptr chaisng leverage.
  2. 可以利用数据依赖的特性,在handler里实现逻辑,比如transfer 数据结构,或者oom exception.

Reference

  1. https://www.ssrc.ucsc.edu/media/pubs/329b041d657e2c2225aa68fb33e72ecca157e6df.pdf
  2. https://arxiv.org/pdf/2204.03289.pdf

SMDK 三星的CXL开发套件 (SK海力士的HMSDK)

这个是干啥的?

三星和海力士都出了他们自家的prototype,暂时的大概意思是PCIe attached FPGA+DDR5模拟CXL.mem逻辑的Proof of Concept。因为CPU的CXL2.0还没出来,与之对应的cfmws type3(带pmem的读写)指令还没实现,所以一个通过 PCIe4.0 连接的CXL.mem逻辑很容易实现,也很容易先完成性能PoC。现在听人说三星用的rambus IP的延时不好于demisifying那篇文章。

与PMDK的比较

ndctl

PMDK 的 hw/sw interface 实现在 ndctl 中(之前做PM re的时候玩过),有给iMC的指令,告诉他们什么模式启动(FSdax/devdax/Memory Mode)然后pmdk底下你issue clflush等指令还是会需要FS来维护index和crash atomicity.

SMDK 在kernel启动的时候会把SRAT(memory affinity)/CEDT(CXL Early Discovery Table)/DVSEC(Designated Vendor-Specific Extended Capability) 三选一BIOS启动参数传给kernel,告诉ACPI的哪个地址有cxl device,intel为了制定标准,把cxl ctl 也集成进ndctl了。这个命令可以获得hw信息、创建label、group等。主要的逻辑都是一样的。新的机器,只要实现了cxl.mem,内核里都会提供cxl 这个command做类似的事情。现在悬而未决的是管理cxl内存hardware axiliary的hot page inspection,用kernel里的hmm还是iouring管理cxl.cache或.mem。

in-Kernel zone memory management

在启动的时候会configure一个memory channel type在(mm/kalsr.c中我们可以看到configure过程,和pmem e820设备不同区域,所以会call在 driver/cxl/exmem.c 下的启动程序,被configure成exmem),所有的PCIe/CXL logic都写在硬件的PoC上了

写PCIe设备的时候(先发出mov CPU地址, PCIe DMAed address, mov在DMA设备读到mmio的时候retire,PCIe设备会从DMA地址读到自己的BAR并拷贝到device RAM中。三星做的是在这里完整的模拟了CXL的过程,传输层,事物层。物理层还是走PCIe5.0。如果是反过来mov则是逆过程。板上实现了IOMMU与否不重要,如果没实现只要有DMA就行了。

如果我写一段地址到exmem mapped 的memory 上,三星的设备会对应接收到DMA请求并开始PoC板上的写内存请求,kernel 在page level会check这个page是不是在exmem上(只需要移位操作比较虚拟内存就可以了)。由于PCIe内存还是相对较慢的,最快走一次PCIe5.0也要300ns,这个模拟还是只能看看样子。我觉得傻逼在于1.复用mmap的flag来做内存分配器实际上是在分配时做决定,并不和numa allocator逻辑一样。2.mmap对于deferrable write的cxl内存并不友好。


他们的road map支持在不同的cxl node/单个node做expander来configure不同的zone。

libnuma integration

三星在libnuma中插入了新的zone,以暴露借口给他们的smalloc。

jemalloc integration

给的是jemalloc的接口,因为zonewise 的用户态内存分配器已经被研究的很透彻了。

YYW的尝试

我尝试在numa上测性能,没用他们的kernel,问题是lazy allocation,如monetdb mmap一块很大内存是很难搞的。

Reference

  1. https://www.youtube.com/watch?v=Uff2yvtzONc
  2. https://www.youtube.com/watch?v=dZXLDUpR6cU
  3. https://www.youtube.com/watch?v=b9APU03pJiU
  4. https://github.com/OpenMPDK/SMDK
  5. PCIe 体系结构
  6. SMT: Software Defined Memory Tiering for Heterogeneous Computing Systems With CXL Memory Expander
  7. https://www.arxiv-vanity.com/papers/1905.01135/
  8. https://arxiv.org/pdf/2303.15375v1.pdf

NFSlicer: Data Movement Optimizationfor Shallow Network Functions

最近一直在想网络SmartNIC延时的问题,发现Alex发过这篇,差不多是NSDI23的水平了。NF是用于抽象firewall/load balencer的函数,这些函数的语义会被记录在SmartNIC上。同时做一些offload的操作。这块陈昂做的很多。

传统的NIC只会做hardwired处理器操作,如TSO/LRO/checksum,用SmartNIC很自然就想到先抽象这些操作为network function,问题卷到现在演变成了谁能把serverless/ML的函数放在SmartNIC上更多,谁就顶会。

用一种SmartNIC+NIC offload pipeline的方式,把slice&splice 做的更低时延,但是这有个条件,绝大多数NF都是shallow的情况, 否则tail latency for pipeline会变得异常高.

他们觉得用上了CAT+DDIO的 private caches, LLC, and memory 都还不是bottleneck, 重在以下TTL的pipeline数据通路.

Reference

  1. AlNiCo: SmartNIC-accelerated Contention-aware Request Scheduling for Transaction Processing
  2. Automated SmartNIC Offloading Insights for Network Functions
  3. https://borispis.github.io/files/2022-nicmem-slides.pdf