来自 Cloudflare 的开发人员 关于开展优化 Linux 内核中磁盘加密性能的工作。 结果，他们做好了准备 对于子系统 Crypto API，使得综合测试中的读写吞吐量增加一倍以上，并将延迟减半。 在真实硬件上进行测试时，加密开销几乎减少到使用未加密数据的磁盘时观察到的水平。
Cloudflare 使用 dm-crypt 来加密用于在 CDN 上缓存内容的存储设备上的数据。 Dm-crypt 在块设备级别运行，加密写入 I/O 请求并解密读取请求，充当块设备和文件系统驱动程序之间的层。
使用该包评估 dm-crypt 的性能 我们测量了位于 RAM 中的 RAM 磁盘上使用加密和未加密分区的速度，以消除磁盘性能的波动并关注代码性能。 对于未加密的分区，读写性能仍保持在1126MB/s，但启用加密后速度有所下降 7的时间 达到 147 MB/s。
起初，人们怀疑内核密码系统中使用了低效算法。 但测试使用了最快的算法 aes-xts，具有 256 个加密密钥，其运行“cryptsetup benchmark”时的性能比测试 RAM 磁盘时获得的结果高出两倍多。 使用 dm-crypt 标志进行性能调整的实验没有产生结果：当使用“--perf-same_cpu_crypt”标志时，性能甚至下降到 136 MB/s，而当指定“--perf-submit_from_crypt_cpus”标志时，它仅增加至 166 MB/秒。
深入分析操作逻辑发现，dm-crypt 并不像看上去那么简单——当 FS 驱动收到写请求时，dm-crypt 并不会立即处理它，而是将其放入“kcryptd”队列中，这使得不是立即解析，而是在方便的时候解析。 请求从队列发送到 Linux Crypto API 以执行加密。 但由于 Crypto API 使用异步执行模型，加密也不会立即执行，而是绕过另一个队列。 加密完成后，dm-crypt 可能会尝试使用搜索树对挂起的写入请求进行排序 。 最后，一个单独的内核线程再次以一定的延迟拾取累积的 I/O 请求并将它们发送到块设备堆栈。
读取时，dm-crypt 首先向“kcryptd_io”队列添加一个请求，以从驱动器接收数据。 一段时间后，数据变得可用并被放置在“kcryptd”队列中进行解密。
Kcryptd 向 Linux Crypto API 发送请求，后者异步解密信息。 请求并不总是经过所有队列，但在最坏的情况下，写请求最多会进入队列 4 次，读请求最多会进入队列 3 次。 每次对队列的命中都会导致延迟，这是 dm-crypt 性能显着下降的关键原因。
使用队列是因为需要在发生中断的情况下工作。 2005 年，当 dm-crypt 当前基于队列的操作模型实现时，Crypto API 还不是异步的。 Crypto API转为异步执行模型后，本质上开始使用双重保护。 还引入了队列来节省内核堆栈消耗，但在 2014 年增加队列之后，这些优化就失去了相关性。 引入了额外的队列“kcryptd_io”来克服大量请求到达时导致等待内存分配的瓶颈。 2015年，引入了额外的排序阶段，因为多处理器系统上的加密请求可能会无序完成（而不是顺序访问磁盘，而是以随机顺序进行访问，并且CFQ调度程序无法有效工作）。 目前，当使用SSD驱动器时，排序已经失去了意义，内核中不再使用CFQ调度器。
考虑到现代驱动器变得更快、更智能，对 Linux 内核中的资源分配系统进行了修订，并重新设计了一些子系统，Cloudflare 工程师 dm-crypt 有一个新的操作模式，消除了不必要的队列和异步调用的使用。 该模式由单独的标志“force_inline”启用，并将 dm-crypt 引入加密和解密传入请求的简单代理的形式。 通过显式选择在同步模式下运行且不使用请求队列的加密算法，优化了与 Crypto API 的交互。 为了与 Crypto API 同步工作，有 使用FPU/AES-NI加速并直接转发加解密请求的模块。
因此，在测试 RAM 磁盘时，dm-crypt 的性能可以提高一倍以上 - 性能从 294 MB/s (2 x 147 MB/s) 增加到 640 MB/s，非常接近裸加密的性能（696 MB /秒）。
在真实服务器上测试负载时，新实施显示的性能非常接近在不加密的情况下运行的配置，并且在具有 Cloudflare 缓存的服务器上启用加密对响应速度没有影响。 未来，Cloudflare 计划将准备好的补丁转移到主 Linux 内核，但在此之前，它们需要重新设计，因为它们针对特定负载进行了优化，并且并未涵盖所有应用领域，例如低端加密。 - 为嵌入式设备供电。
来源： opennet.ru