linux - Linux malloc()在ARM与x86上的行为是否有所不同？

Question

这个站点上有很多有关内存分配的问题，但是我
找不到专门解决我关注的问题。 Thisquestion
似乎最接近，它导致我找到thisarticle，所以...我比较了
(虚拟)桌面x86上包含的三个演示程序的行为
Linux系统和基于ARM的系统。

我的发现是详细的here，但是
快速摘要是:在我的桌面系统上，
文章似乎表明demo3始终取决于内存量
已分配-即使禁用了交换。例如，它高兴地“分配” 3
GB的RAM，然后在程序开始实际运行时调用OOM杀手
写所有的内存。在禁用交换的情况下，将调用OOM杀手
据说只写了3 GB malloc()的610 MB之后
可用。

该演示程序的目的是为了证明Linux的这一有据可查的“功能”，因此这不足为奇。
但是在基于i.MX6的嵌入式目标工作时，行为有所不同，malloc()似乎在告诉它有多少内存
总是分配(？)下面的程序(从文章中逐字复制)
当malloc()时，在第二个循环中被OOM杀死:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define N       10000

int main (void) {
        int i, n = 0;
        char *pp[N];

        for (n = 0; n < N; n++) {
                pp[n] = malloc(1<<20);
                if (pp[n] == NULL)
                        break;
        }
        printf("malloc failure after %d MiB\n", n);

        for (i = 0; i < n; i++) {
                memset (pp[i], 0, (1<<20));
                printf("%d\n", i+1);
        }

        return 0;
}

简而言之， 我的问题是:为什么 i == n程序(或其他一些程序)
不幸的OOM杀手的受害者—总是在我的 demo3上早就被杀死
桌面系统(暗示 i == n是骗子)，但只会被杀死
在我们的i.MX6 ARM目标上使用 malloc()时(暗示 i == n可能会告诉
真相)？这个区别是libc和/或内核版本的函数吗，还是
还有什么吗我可以得出结论，如果出现以下情况， malloc()将始终返回NULL
在此目标上分配失败？

注意:每个系统的一些详细信息(请注意 malloc()和 overcommit_memory两者的值相同):

# Desktop system
% uname -a
Linux ubuntu 3.8.0-33-generic #48-Ubuntu SMP Wed Oct 23 17:26:34 UTC 2013 i686 i686 i686 GNU/Linux
% /lib/i386-linux-gnu/libc.so.6 
GNU C Library (Ubuntu EGLIBC 2.17-0ubuntu5.1) stable release version 2.17, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.7.3.
Compiled on a Linux 3.8.13 system on 2013-09-30.
Available extensions:
    crypt add-on version 2.1 by Michael Glad and others
    GNU Libidn by Simon Josefsson
    Native POSIX Threads Library by Ulrich Drepper et al
    BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<https://bugs.launchpad.net/ubuntu/+source/eglibc/+bugs>.
% cat /proc/sys/vm/overcommit_memory
0
% cat /proc/sys/vm/overcommit_ratio 
50

# i.MX6 ARM system
# uname -a
Linux acmewidgets 3.0.35-ts-armv7l #2 SMP PREEMPT Mon Aug 12 19:27:25 CST 2013 armv7l GNU/Linux
# /lib/libc.so.6
GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.7.3.
Compiled on a Linux 3.0.35 system on 2013-08-14.
Available extensions:
    crypt add-on version 2.1 by Michael Glad and others
    Native POSIX Threads Library by Ulrich Drepper et al
    BIND-8.2.3-T5B
libc ABIs: UNIQUE
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
# cat /proc/sys/vm/overcommit_memory
0
% cat /proc/sys/vm/overcommit_ratio 
50

背景:我们正在尝试决定如何处理内存不足的情况
面向媒体的嵌入式应用程序，并想知道对于该特定目标，我们是否可以信任 overcommit_ratio在分配失败时提醒我们。我对台式机Linux的经验
应用程序使我认为答案肯定不是，但是现在我不确定。

Answer 1

一点背景
malloc()不会说谎，内核虚拟内存子系统会说谎，这是大多数现代操作系统上的常见做法。当您使用malloc()时，实际上是这样的:

malloc()的libc实现检查其内部状态，并将尝试通过使用各种策略来优化您的请求(例如尝试使用预分配的块，分配比预先请求的更多的内存...)。这意味着实现会影响性能，并会稍微减少内核请求的内存量，但这在检查“大数字”时并没有实际意义，就像您在测试中所做的那样。

如果预分配的内存块中没有空间(请记住，内存块通常很小，约为128KB至1MB)，它将要求内核提供更多的内存。实际的系统调用在一个内核和另一个内核(mmap()，vm_allocate() ...)之间有所不同，但其目的基本相同。

内核的VM子系统将处理该请求，并且如果发现它是“可接受的”(稍后将对此主题进行更多介绍)，它将在该请求任务的内存映射中创建一个新条目(我正在使用UNIX)术语，其中task是具有其所有状态和线程的进程)，并将所述映射条目的起始值返回给malloc()。

malloc()将记录新分配的内存块，并将适当的答案返回给您的程序。

好的，所以现在您的程序已成功分配了一些内存，但事实是 尚未将单个页面的物理内存(x86中为4KB)分配给您的请求，而(实际上，这过于简化了) ，因为附带地可以使用某些页面来存储有关内存池状态的信息，但这使说明这一点变得更加容易。

因此，当您尝试访问此最近分配的内存时会发生什么？ 分段错误。令人惊讶的是，这是一个鲜为人知的事实，但是您的系统始终在生成分段错误。然后，您的程序被中断，内核进行控制，检查地址错误是否对应于有效的映射条目，获取一个或多个物理页面并将其链接到任务的映射。

如果您的程序尝试访问不在您任务中的映射条目内的地址，则内核将无法解决该故障，并将向其发送信号(或非UNIX系统的等效机制)，并指出这个问题。如果程序本身不处理该信号，它将被臭名昭著的Segmentation Fault错误杀死。

因此，当您调用 malloc()时，并不会分配 物理内存，而是在您实际访问该内存时分配。这使操作系统可以执行一些漂亮的技巧，例如磁盘分页，清理和过量使用。

这样，当您询问特定进程正在使用多少内存时，您需要查看两个不同的数字:

虚拟大小:已请求的内存量，即使实际上并未使用。

驻留大小:实际使用的内存，由物理页面支持。

多少过量使用就足够了？

在计算中，资源管理中的一个复杂问题。您有多种策略，从最严格的基于功能的系统到更轻松的内核行为，例如Linux(带有 memory_overcommit == 0)，这些策略基本上将允许您请求内存，直到任务允许的最大映射大小(这是一个限制，取决于架构)。

在中间，您有OS(如文章中提到的Solaris)，它将任务的虚拟内存量限制为( physical pages + swap disk pages)的总和。但是，不要被您所引用的文章所迷惑，这并不总是一个好主意。如果您要同时运行Samba或Apache服务器，同时运行数百至数千个独立进程(这会因碎片而导致大量虚拟内存浪费)，则必须配置大量的交换磁盘，否则您的系统将耗尽虚拟内存，同时仍有大量可用RAM。

但是，为什么内存过量使用在ARM上的工作方式不同？

没有。至少这不是应该的，但是ARM供应商有疯狂的倾向对他们随系统分发的内核进行任意更改。

在您的测试案例中，x86机器正在按预期工作。当您以较小的块分配内存，并且 vm.overcommit_memory设置为0时，由于在32位计算机上运行它，因此可以填充3GB行中的所有虚拟空间。您尝试在64位上执行此操作，则循环将运行直到n == N)。显然，当您尝试使用该内存时，内核会检测到物理内存越来越少，并激活了OOM杀手级对策。

在ARM上应该相同。并非如此，我想到了两种可能性:

overcommit_memory禁止使用(2)策略，这可能是因为有人在内核上以这种方式强制使用了它。

您正在达到任务允许的最大 map 大小。

正如在ARM上的每次运行一样，您在malloc阶段获得了不同的值，我将放弃第二个选项。确保启用 overcommit_memory(值0)，然后重新运行测试。如果您可以访问这些内核源代码，请查看它们，以确保内核尊重该sysctl(如我所说，某些ARM供应商喜欢对其内核进行讨厌的操作)。

作为引用，我在Efika MX(iMX.515)的QEMU上模拟了vertilepb上运行了demo3。如在32位计算机上所预期的那样，第一个停止将malloc分配为3 GB，而另一个则更早地将其分配为2 GB。这可能令人惊讶，但是如果您查看其内核配置( https://github.com/genesi/linux-legacy/blob/master/arch/arm/configs/mx51_efikamx_defconfig)，则会看到以下内容:

CONFIG_VMSPLIT_2G=y
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0x80000000

内核配置了2GB/2GB的拆分，因此系统运行正常。