分配大 (32mb) 连续区域答案

【问题标题】：allocate large (32mb) contiguous region分配大 (32mb) 连续区域
【发布时间】：2011-11-04 06:21:32
【问题描述】：

是否可以在运行时从内核代码分配大的（即 32mb）物理上连续的内存区域（即不使用 bootmem）？从我的实验来看，无论我使用什么 GFP 标志，似乎都无法成功获得超过 4mb 的块。根据我读过的文档，GFP_NOFAIL 应该让 kmalloc 只等待释放请求的数量，但据我所知，如果您请求的数量超过可用数量，它只会使请求无限期挂起 -它似乎没有积极尝试释放内存来满足请求（即 kswapd 似乎没有运行）。有没有办法告诉内核积极地开始交换东西以释放请求的分配？

编辑：所以我从 Eugene 的回复中看到，不可能从单个 kmalloc 获得 32mb 区域....但是有没有可能以更骇人听闻的方式完成它？比如确定最大的可用连续区域，然后手动迁移/交换它两侧的数据？

或者这样的事情怎么样：

1) Grab a bunch of 4mb chunks until you're out of memory.
2) Check them all to see if any of them happen to be contiguous, if so,
   combine them.
3) kfree the rest
4) goto 1)

如果有足够的时间运行，这可能行得通吗？

【问题讨论】：

只是好奇，为什么需要 32Mb 的物理连续内存？
从我在内核源代码中看到的（mmzone.h 中 MAX_ORDER 的定义和__alloc_pages_slowpath 的主体），分配了超过 (1
许多嵌入式设备（如手机）的硬件（如相机和编解码器芯片）需要物理上连续的内存区域，因为它们直接写入内存，无需通过 MMU。这通常是使用 bootmem 实现的——在启动时分配一个为他们永久保留的区域，禁止分配给其他任何东西。尽管在内存受限的设备上，这是非常浪费的。我真的很烦，在我只有 512mb 物理内存的手机上，我必须为我几乎从未使用过的硬件永久保留近 100mb。
（续）似乎没有任何理论上的理由表明这是必要的——内核不应该能够按需交换和/或迁移数据以释放必要的区域吗？我意识到所有交换/迁移都需要一些时间，但我愿意等待几秒钟让相机驱动程序在我使用它的极少数情况下加载，如果这意味着释放额外的 100mb 内存在正常使用期间（编解码器芯片使用多个 32mb 的 bank）。
是的，我现在明白为什么需要这么多的连续内存了。谢谢你的解释。

标签： linux-kernel

【解决方案1】：

Mircea 的链接是一种选择；如果您的设备上有 IOMMU，您也可以使用它在内存中的一组非连续页面上呈现连续视图。

【讨论】：

【解决方案2】：

您可能想看看Contiguous Memory Allocator patches。从LWN article来看，这些补丁正是你所需要的。

【讨论】：