关于Controller Memory Buffer（CMB）
每块SSD上，不管是SATA还是PCIE口的，都会有一定量的DRAM来做数据缓存。但是，这个数据缓存对Host端是不可见的，也就是说，Host端的代码是不可能直接使用访存指令访问到这块数据缓存的，这块内存空间并没有被映射到Host物理地址空间中。
我们知道，Host端的程序只能通过访问某个或者某些物理地址从而与SSD控制器通信。通常，Host端的驱动程序会将由上层协议栈准备好的IO指令及数据在Host主存中的基地址（也就是指针）采用Stor指令写入到SSD控制器的前端PCIE控制器模块所暴露的寄存器中，SSD控制器接收到该指针，便可以从Host主存中取回对应的指令及数据从而执行。SSD控制器的这些寄存器会被映射到Host物理地址空间中的某处，该动作由host端PCIE bus driver在枚举PCIE设备之后即执行。底层细节和过程冬瓜哥就不过多描述了。
可以看到，SSD控制器只向host端暴露了很少量的寄存器存储空间，并未将其内部的数百兆甚至上GB的DRAM空间映射到host物理地址空间。而且，驱动程序先把对应的指针通知给SSD控制器，然后SSD控制器需要主动从Host主存取指令和数据。有人可能会想，为何驱动程序不直接将指令及数据写入到SSD的DRAM中呢？原因是CPU如果把这事都自己干了，那就忙不过来了，会深陷到Load/Stor指令移动数据，其他活就没法干了。SSD控制器上有个DMA模块，在收到指针之后，DMA模块会主动读取host主存，此时host CPU可以做其他事情。
但是如果CPU将整条指令而不是指针直接写到SSD端的DRAM的话，并不耗费太多资源，此时能够节省一次PCIE往返及一次SSD控制器内部的中断处理。于是，人们就想将SSD控制器上的一小段DRAM空间映射到host物理地址空间从而可以让驱动直接写指令进去，甚至写一些数据进去也是可以的。这块被映射到host物理地址空间的DRAM空间便被称为CMB了。
CMB对NNMe Over Fabric场景下非常有用，因为节省了一趟往返，如果外部网络时延较大的话，每笔IO都节省了一次往返，每秒便能增加不少IOPS。
CMB还有另外一种应用场景，在5月19日的中国云计算大会上冬瓜哥有个分享，会向大家介绍，这里就不多说了。
关于Host Memory Buffer（HMB）
有些SSD产品为了节省成本，板载DRAM很小，或者根本没有。就像有些显卡没有板载显存一样。但是并不表示它们不需要DRAM。它们的DRAM可以与host端的主存共享，也就是分配一块主存用作其DRAM，这些外部设备控制器可以通过PCIE接口访问host端的DRAM。共享显存的模式下，系统bios会直接分割出一块连续的DRAM给显卡使用，此时，host端OS根本看不到这块空间，BIOS会配置系统IO桥上的地址路由表以及地址范围寄存器，从而实现不同访存请求的路由。
NVMe协议中也定义了这种场景，只不过，并非像共享显存那样直接从bios层面分配连续的空间，而是由NVMe驱动在OS所管理的物理地址空间内分配对应容量的RAM给SSD控制器使用，这段空间物理上可以不连续，NVMe驱动将对应的基地址+长度的列表推送给SSD控制器，SSD控制器需要将对应的列表更新到内部的寄存器中用于访存查找。这样，SSD控制器就可以将比如FTL映射表存储到host端的这块RAM中，这也就意味着，每一笔IO请求发送到SSD之后，SSD控制器需要通过PCIE来访问host端的这块RAM从而提取出映射表中对应的条目来查找对应IO目标逻辑地址所被映射到的物理地址，也就意味着每一笔IO都需要产生更多的PCIE流量，时延就会大增。
当主机突然掉电之后，host端的这块RAM中数据就会丢失。重启之后，SSD需要从Flash Page中保存的元数据重构出这张大表，再次写入host端的ram。只不过，这个动作只有OS启动之后，NVMe驱动加载之后，才能执行，因为每次启动NVMe分配的这块RAM对应物理地址可能都不同。这会产生一个问题，如果用该SSD当做启动盘的话，重启之后bios阶段是无法给SSD分配host内存的，即便分配了，OS也不会认，除非改OS的内存管理部分。此时，SSD必须先使用其板载的小容量SRAM/DRAM，性能会比较差。OS启动后再后台继续重构FTL表。
HMB使用场景比较受限制，所以目前还没有出现使用HMB机制的SSD。
其他相关阅读（点击可直接进入）：
《关于SSD元数据及掉电保护的误解 》
《 关于闪存FTL的Host Base和Device Based的误解 》
《帮你梳理一下各种存储协议及接口》
2518
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
