我的系统内存充足（24GB的服务器）。在我的系统中，内核空间分配了320MB和120MB用于崩溃内核。其余的内存用于其他目的。但是，当我使用__get_free_pages()分配顺序为 11 的连续页，内核无法分配 2^10 页。为什么？
根据制作linux http://www.makelinux.net/ldd3/chp-8-sect-3
order 的最大允许值为 10 或 11（对应于 1024
或 2048 页），具体取决于架构。的机会
order-10 分配在除新启动的系统之外的任何系统上均成功
然而，具有大量内存的系统却很小。
为什么会这样？我的系统中每个页面为4KB（4096字节），2^10页面=1024页面，总大小为1024*4096=4 194 304（字节）~4MB。它只有4MB的连续空间，而且内核非常小：vmlinuz只有2.1MB，initrd只有15MB。整个内核的总内存消耗约为300MB。内核分配 4MB 的连续页肯定绰绰有余。即使在具有 1GB/3GB 内核/用户的普通机器中，并且确保内核不会用完整个 1GB。但是只有 4MB 连续页的分配怎么会失败呢？而且我认为，在内核空间中，内存并不是分散在物理内存中（由于虚拟内存映射），而是线性且连续的。
我尝试首先使用 2^10 页分配加载内核模块，但失败并转储堆栈跟踪：
[ 6.037056] [<ffffffff810041ec>] dump_trace+0x86/0x2de
[ 6.037063] [<ffffffff8122fe83>] dump_stack+0x69/0x6f
[ 6.037070] [<ffffffff8108704e>] warn_alloc_failed+0x13f/0x151
[ 6.037076] [<ffffffff8108786a>] __alloc_pages_nodemask+0x80a/0x871
[ 6.037081] [<ffffffff81087959>] __get_free_pages+0x12/0x50
如果我没记错的话__get_free_pages uses 好友分配 http://en.wikipedia.org/wiki/Buddy_allocation，这不仅does将其分配分散在整个物理内存中，它是在最坏的可能后续尝试分配大的连续块的模式。如果我的计算正确的话，在你的物理 RAM 为 24GB 的系统上，even if除了伙伴分配之外，没有任何空间被任何东西占用，因此需要不到 8192 个 order-0 (4KB) 分配来渲染 4MB 块的分配__get_free_pages不可能的。
有一种东西叫做连续内存分配器 http://lwn.net/Articles/447405/，它应该解决设备驱动程序对大量物理连续分配的真正需求；截至 2011 年 6 月，它还没有出现在官方内核中，但那已经是一年多前的事了。你应该调查一下。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
