在运行 Centos 的大型 Linux 系统上，我们有时会看到类似的消息
kernel: <program_name>: page allocation failure: order:<N>, mode:0xNNNN
阅读如下文章：
https://utcc.utoronto.ca/~cks/space/blog/linux/DecodingPageAllocFailures
https://utcc.utoronto.ca/~cks/space/blog/linux/WhyPageAllocFailure
听起来这些消息大多是由于内核中的一些错误的内存检查逻辑而导致的虚假警告。
我理解“order:0”消息很重要，但我们从未收到过这些消息。
我们确实收到了像上面那样的无用的高阶消息，它们只是“无需采取任何行动”的喷发，堵塞了我们的 /var/log/messages 文件。
一页又一页的可忽略堆栈转储使得很难发现真正的错误。这降低了系统可靠性。
那么，有没有办法将这些消息从 /var/log/messages 文件中重定向出去？
答案1
“虚假”或“糟糕”并不是 Chris 在您链接的博客中得出的结论。他们解释了分配器尝试低阶优先的不直观之处。
通过查看以下内容了解您的工作量：
- 哪个用户空间程序
- 调用跟踪，包括哪些内核子系统发起了请求
- 分配大小的顺序
- 内存区域中每个订单的空闲块
- 内存容量规划，包括总计
/proc/meminfo
将这些详细信息提供给您的发行版的支持人员，或者在 Server Fault 上提供。可以尝试的方法可能包括调整参数或更新的内核。
与 Linux 中记录的许多内容一样，这是printk()基于的。 warn_alloc()无法mm/page_alloc.c单独抑制，但您可以抑制优先级低于 LOGLEVEL_WARNING（定义为 4）的所有消息。有一个sysctl 用于，因此使用/etc/sysctl.d/printk.conf类似
# console_loglevel, default_message_loglevel, minimum_console_loglevel, default_console_loglevel
kernel.printk = 3 4 1 7
请注意，这也会抑制许多其他可能有趣的警告。
或者，您可以集中您的日志记录和警报，并能够处理大量的行。printk + syslog 不仅仅是一个人可以阅读的，还定义如何从噪音中提取您感兴趣的信号。