solaris - mmap会使用连续内存吗？ (在 Solaris 上)

Question

我使用 mmap(只是尝试了解 mmap 的工作原理)来分配 96k 匿名内存，但看起来它将 96k 分成了 64k 和 32k。但是当分配960k时，它只分配一个大小为960k的chunk。什么时候solaris会把分配内存分成几部分？代码:

#define PROT PROT_READ | PROT_WRITE
#define MAP  MAP_ANON  | MAP_PRIVATE
if ((src = mmap(0, 88304, PROT, MAP, -1, 0)) == MAP_FAILED)
    printf("mmap error for input");

if ((src = mmap(0, 983040, PROT, MAP, -1, 0)) == MAP_FAILED)
    printf("mmap error for input");

if ((src = mmap(0, 98304, PROT, MAP, -1, 0)) == MAP_FAILED)
    printf("mmap error for input");

桁架:

mmap(0x00000000, 88304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0)
    = 0xFFFFFFFF7E900000
mmap(0x00000000, 983040, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0)
    = 0xFFFFFFFF7E800000
mmap(0x00000000, 98304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0)
    = 0xFFFFFFFF7E700000

map :

FFFFFFFF7E700000         64     -          -          - rw---    [anon]
    ==> strange is that for 96k, it was broken into 2 part.
FFFFFFFF7E710000         32     -          -          - rw---    [anon]
FFFFFFFF7E800000        960     -          -          - rw---    [anon]
FFFFFFFF7E900000         64     -          -          - rw---    [anon]
FFFFFFFF7E910000         24     -          -          - rw---    [anon]
FFFFFFFF7EA00000         64     -          -          - rw---    [anon]
FFFFFFFF7EA10000         32     -          -          - rw---    [anon]

Answer 1

那是连续的内存，你可以通过地址(F...700000 + 64K = F...710000)来判断，所以我不认为你必须担心这一点。我非常确定需要 mmap 才能在地址空间中为您提供连续的内存。否则它将毫无用处，因为它只给你一个基地址。对于两个不连续的 block ，将无法找到第二个 block 。

所以我猜你的问题是:为什么这在 pmap 中显示为两个 block ？

对此我的回答是“如果我知道的话就很饱了”。但我可以做出明智的猜测，这是任何人在早上这个时候(喝咖啡前)对我的最好期望。

我建议这些 block 之前已分配给另一个(或两个)进程，并已释放回 mmap 内存管理器。我可以看到内存管理器如何合并 block 以形成更大的空闲 block 的两种可能性:

• 一旦内存被释放，它就会执行此操作(不是您的输出显示的情况，没有发生)。
• 它会定期执行此操作，并且在您请求 96K block 之前它还没有抽出时间执行此操作；或
• 它根本不会打扰，因为它足够聪明，可以在向您分配 block 期间执行此操作。

我怀疑是后者，因为内存管理器没有任何问题为您的请求提供两个 block ，因此它显然是为了处理它而构建的。 960K block 可能没有被分段，因为它来自一个更大的 block 。

请记住，这只是猜测(知情，但仍然是猜测)。我已经了解了相当多的 UNIX 内部结构(真正的 UNIX，不是新来的 :-)，但我从来没有必要深入研究 mmap。