3

我正在试验mmap并附带以下示例代码：

    int main() {

    int fd;
    char *filename = "/home/manu/file";
    struct stat statbuf;
    int i = 0;
    char c = *(filename);

    // Get file descriptor and file length
    fd = open(filename, O_RDONLY);
    if (fd == -1) {
        perror("fopen error");
    }
    if (fstat(fd, &statbuf) < 0) {
        perror("fstat error");
    }
    printf("File size is %ld\n", statbuf.st_size);

    // Map the file
    char* mmapA = (char*) mmap(NULL, statbuf.st_size, PROT_READ, MAP_PRIVATE,
            fd, 0);
    if (mmapA == MAP_FAILED) {
        perror("mmap error");
        return 1;
    }

    // Touch all the mapped pages
    while (i < statbuf.st_size) {
        c = mmapA[i];
        i++;
    }
    c++;

    // Close file descriptor
    if (close(fd) == -1) {
        perror("close");
        return 1;
    }

    //Unmap file
    munmap(mmapA, statbuf.st_size);

    return EXIT_SUCCESS;
}

文件大小为 137948 字节 = 134.7 KB。为了检查程序的内存，我使用顶部，主要是 RES 和 VIRT 列。我在三个不同的地方寻找这些值：

  1. 就在mmap通话之前
  2. 就在mmap通话后
  3. 在读取所有映射内存以将文件有效加载到主内存后（页面错误后）

top 报告的值是

  1. 维特 = 1828 资源 = 244
  2. VIRT = 1964 RES = 248
  3. VIRT = 1964 RES = 508

1964 - 1828 = 136，我猜是千字节，因此完全匹配文件的大小。

但我无法理解 508 - 248 = 260 的 RES 差异。为什么它与虚拟内存大小和文件大小不同？

4

1 回答 1

2

有一件事是肯定的：结果取决于系统的状态，而不仅仅取决于正在运行的应用程序。在我的机器上，前两次运行程序时 RES 增加了 136 kB，但随后的运行根本没有增加 - 可能操作系统已经将整个文件放在缓存中。有趣的是，值本身在运行之间存在显着差异。在第一次运行中，RES 的跳跃是从 344 到 480 kB，但后面运行的 RES 值一直为 348 kB。SHR 也有类似的变化：第一次跳跃 136 kB，后来没有变化。

dd我可以通过在运行应用程序之前覆盖后来用零映射的文件来随意强制原始案例（136 kB 跳转） 。

我查看了pmaps输出，但在两种情况下都完全相同，并且在调用mmap().

我无法在这里重现超大的 RES 跳跃，但这是你可以做的。假设您的二进制文件编译为a.out. 在 之后 插入 10 秒的睡眠，mmap()然后再插入 10 秒的睡眠munmap()。这提供了一个时间窗口来转储有趣的信息。我们将从/proc哪些文件中读取驻留在内存中的确切文件。为此，请在一次运行中打开终端中的两个选项卡

./a.out

然后立即在另一个选项卡中：

for ((i=0;i<4;i++)); do cat /proc/$(ps -fe | egrep '[a]\.out' | awk '{print $2}')/smaps > smaps.$i; sleep 5; done

这将在四个单独的文件中创建程序地图状态的 4 个快照。连续编号的快照之一之间的差异应显示 RES 大小激增期间的变化。在示例运行期间，在我的机器上，快照 1 和 2 之间存在差异，并且更改为 [注意我更改了映射文件的名称，但在这里并不重要]：

user@machine:~$ diff -u smaps.{1,2}
--- smaps.1     2012-04-19 00:01:46.000000000 +0200
+++ smaps.2     2012-04-19 00:01:51.000000000 +0200
@@ -84,13 +84,13 @@
 MMUPageSize:           4 kB
 b782f000-b7851000 r--p 00000000 08:05 429102     /tmp/tempfile
 Size:                136 kB
-Rss:                   0 kB
-Pss:                   0 kB
+Rss:                 136 kB
+Pss:                 136 kB
 Shared_Clean:          0 kB
 Shared_Dirty:          0 kB
-Private_Clean:         0 kB
+Private_Clean:       136 kB
 Private_Dirty:         0 kB
-Referenced:            0 kB
+Referenced:          136 kB
 Swap:                  0 kB
 KernelPageSize:        4 kB
 MMUPageSize:           4 kB

发生的事情正是应该发生的事情：映射文件最初根本不驻留，后来有 136 kB 驻留。

在您的系统上，差异应该引导您找到 RES 中额外更改的来源 - 您应该能够找出Rss值更改的其他文件的名称。有些条目不是文件，而是其他内存区域，例如，您可能会找到诸如[heap]和之类的标记[stack]。这也应该证明或反驳 nos 关于加载系统库和堆栈使用增长的建议。

于 2012-04-18T22:16:35.723 回答