Linux内核模块kfifo_alloc()申请128MB失败，如何增大分配尺寸？

问题1：kfifo_alloc申请128MB失败的原因及替换kmalloc的可能性 #

• 失败原因：内核kmalloc()分配的是连续物理内存块，当前系统的KMALLOC_MAX_SIZE限制了单次连续物理内存分配的上限为32MB。用户空间malloc()分配的是虚拟地址连续的内存，物理地址可以不连续，内核通过页表映射拼接虚拟地址，因此能轻松申请大尺寸内存，两者的内存分配机制完全不同。
• 替换可能性：kfifo_alloc()底层依赖kmalloc()的连续内存实现，官方没有提供直接改用vmalloc()（内核中等价于用户空间malloc的非连续内存分配函数）的版本。kfifo的环形缓冲区设计依赖内存连续性简化读写逻辑，直接替换会破坏原有实现逻辑。

问题2：能否增大KMALLOC_MAX_SIZE？ #

可以，但需要重新编译内核。KMALLOC_MAX_SIZE是内核编译时的配置参数，由SLUB/SLAB内存分配器的相关选项控制。在Linux 5.4 aarch64架构下，可通过make menuconfig找到SLUB分配器的内存块尺寸配置选项，调整最大块尺寸后重新编译内核及驱动模块。

问题3：将KMALLOC_MAX_SIZE设为256MB的后果 #

• 内存碎片风险飙升：大尺寸连续内存块会加速内存碎片化，系统运行一段时间后，可能出现小尺寸内存块都无法分配的情况，严重影响其他内核模块和系统服务的稳定性。
• 内存资源浪费：SLUB分配器会为每个尺寸的内存块创建缓存，大尺寸缓存会占用更多内存资源，即使未被使用也会预留部分内存用于缓存管理。
• 系统启动延迟：内核初始化时需要为大尺寸内存缓存做准备，会延长系统启动时间。
• 兼容性隐患：部分依赖默认kmalloc尺寸的驱动或内核组件可能出现兼容性问题，尤其是那些假设kmalloc最大尺寸较小的代码。

问题4：驱动需要大于32MB的FIFO时的推荐方案 #

最推荐的方案是基于vmalloc实现自定义无锁环形缓冲区，或者采用以下替代方案：

1. 自定义vmalloc环形缓冲区
   • 在进程上下文用vmalloc(128*1024*1024)分配虚拟地址连续的非物理内存。
   • 自行实现单生产者单消费者无锁逻辑：用原子变量（如atomic64_t）或READ_ONCE/WRITE_ONCE宏保证读写指针的原子性，中断上下文仅执行数据写入操作（提前在进程上下文分配好内存）。
2. 基于kfifo_init的自定义内存方案
   • 先用vmalloc()分配内存，再调用kfifo_init()初始化kfifo，传入自定义内存地址和尺寸。需注意：kfifo原生设计针对连续物理内存，该方式需充分测试验证兼容性。
3. 块链式队列方案
   • 若数据以固定1MB块传输，可使用内核链表或skb_queue将每个1MB块作为节点存入队列。该方式无需连续内存，适合大尺寸缓冲，但需注意节点管理的开销。

内容的提问来源于stack exchange，提问作者Mehmet Fide