LWN: kmalloc( )确保对齐

Alignment guarantees for kmalloc()

By Jonathan Corbet

May 8, 2019

LSFMM

kmalloc()是kernel里最基础的内存分配API，用于针对较小的对象分配内存。通常，开发者不用操心返回的memory是否有对齐（alignment）问题，反正一直用的好好的。不过Vlastimil Babka在2019 Linux Storage, Filesystem, and Memory-Management Summit上的一个全员讲座里面指出，kmalloc()有时会有一些出人意料的行为。他建议今后应该让代码更严格，确保kmalloc能给出对齐的memory，从而避免意外。

Babka认为kmalloc()应该针对他所分配的对象而满足他们天生要求的对齐条件（natural alignment）。这里的natural alignment是指分配的内存起始地址需要是三个数字的整数倍：ARCH_KMALLOCMINALIGN（缺省是8个byte），cache-line size（对较大对象来说最好是cache line align的），还有object的size（如果是2的幂次的话）。通常用这三个值的最小公倍数即可。

多数时候，kmalloc()返回的memory会是满足natural align的要求的，都是2的幂次的分配大小。这是因为slab page分配器的实现决定的。不过如果打开了SLUB debug选项，或者使用了SLOB allocator的话，就会有例外。大家不太担心SLOB，毕竟用的人较少，但是SLUB debug比较常用，可能会让开发者碰到问题的时候想不到这个地方。例如平常分配到的都是满足natural align的内存对象，但是突然某一天他们打开SLUB debug选项，然后程序就运行不正常了。Babka已经看到一些Stack Overflow问题都是在问kmalloc()是否能保证满足对齐要求的，不过那些回答都不太对。XFS就肯定会在不满足block-size对齐的情况下会出异常。这里有一些workaround方案，不过就算这样，XFS还是很依赖具体底层实现，而没法强制确保alignment。这些workaround也会导致内存浪费的更多。

James Bottomley问道为什么XFS会有这种对齐需求。Christoph Hellwig回答指出XFS只是一个暴露出这个问题的报信者，而对I/O buffer有比较特别的对齐需求的那些外设来说，这里肯定会有问题。Matthew Wilcox开玩笑说如果block layer能做bounce buffering的话就没问题了。Hellwig很认真回答说开发者都在尽量消除bounce buffering机制，不应该再加回来了。此外，还有别的地方也用kmalloc()分配I/O buffer，它们也会碰到这种问题。

可能有个解决方案，就是对那些明知道自己需要有特定对齐要求的代码，去调用kmem_cache_alloc()来创建特定对齐size的一些cache。不过这样就需要对各种可能分配的size都需要先创建对应的cache。Dave Hansen觉得既然缺省行为是保证正确性，那么也许可以在按照指定alignment进行分配之后，再拼接成缺省的cache，这样就能降低overhead了。Babka觉得这个实现就太乱了。开发者们讨论了如何实现这个机制，不过最后没有达成一致意见。

还有一个可能的解决方案，就是创建一个kmalloc_aligned（）函数，可以接受一个指定的alignment参数。这样当需要用到的alignment比起natural alignment值要大的场景会很有用。开发者也会很快知道这个API，然后会慢慢了解合适需要用到。不过，没法保证用这个API的地方都用对了。

Babka觉得，应该让kmalloc()实现里面来确保这点，在分配的size是2的幂次的时候，一定要返回满足natural align条件的memory object。在SLAB里面什么都不用改，SLUB如果不打开debug的话也什么都不用改。因此只有在SLUB debug打开的情况下，需要修改代码，这里会引入一些代价，例如浪费一些memory等。而如果在SLOB里面也实现这个机制来确保的话，会让他已经碎片化的heap变得更加雪上加霜。

Wilcox觉得SLUB的red-zone debugging机制（就是用来监测是否访问超出了分配的范围 ） 可能没有什么真的好处吧，毕竟现在KASAN实现了这个功能，干脆把它删掉？不过其他开发者还是有人觉得这个功能很有用处。KASAN的overhead比较大，并且一定要编译进kernel，而red-zone检测可以在运行后动态打开。Ted Ts'o觉得他也想打开red zone机制，打开KASAN通常要花很多功夫。Hellwig也说每次当有人提出增加一个新的数据结构的时候，他都会先打开red zone来看看。

Babka指出，虽然确保alignment能让kmalloc()的用户用起来更加简单一些，不过这也会引入一些代价。打开SLUB debug的kernel通常都会有一些性能损失，SLOB则更加低效了。此外如果实现严格模式的话，就会限制slab allocator今后可能的一些改进方向，例如Christoph Lameter就指出这回让今后在object里面增加metadata更加困难。

Bottomley建议做一点变化：只针对512 byte一下的object来做natural alignment，而对更大的object只保证512-byte align。分配的memory要是比一个page还大的话，那应该直接做page alignment。Babka认为这种特殊策略会让实现过于复杂。Ts'o觉得不值得花太多精力去解决所有的潜在问题，只要多花一点memory能解决那些更常出现的问题，那还是值得的。

Hugh Dickins替SLOB用户感到比较担心。通常SLOB用户都会在一些内存资源很少的设备上运行系统，他们可能会收到更多影响，例如分配memory的耗时更常，占用的内存空间也会多。可能不久之后内核开发者就会听到他们的反馈。Babka回复认为，情况可能不一定那么糟糕，毕竟SLOB的heap里面有更多的内存碎片空洞，不过最终都被分配的小对象给填满了。Wilcox指出SLOB会在分配出来的对象前面多保留4 byte来存储对象的size，这种会让需要满足对齐条件的情况很难处理。Bobka答应后续他会多看看SLOB里面的损耗，不过他也不太希望因为SLOB（毕竟用户非常少）而阻碍这个机制的合入。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～