1

我的程序正在使用大页面。为此，它打开文件如下：

oflags = O_RDWR | O_CREAT | O_TRUNC;
fd = open(filename, oflag, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);

hugetlb 文件系统在哪里filename。这样可行。然后我的程序可以mmap()创建文件描述符。但是如果我的程序被杀死，文件仍然存在......并且在大页面文件系统中，剩余文件被阻塞内存，如以下命令所示（876！= 1024）：

cat /proc/meminfo  | grep Huge

AnonHugePages:    741376 kB
HugePages_Total:    1024
HugePages_Free:      876
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

因此，由于我的程序没有将文件共享给其他任何人，因此使用 O_TMPFILE 标志创建临时文件对我来说是有意义的。所以我尝试了：

oflags = O_RDWR | O_TMPFILE;
fd = open(pathname, oflag, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);

其中 pathname 是hugetlbfs 的点。失败（由于我无法解释的原因）并出现以下错误：

open failed for /dev/hugepages: Operation not supported

为什么？更重要的是：如何保证我的程序正在使用的所有大页面都被释放？

是的：我可以捕捉到一些信号（例如SIGTERM）；但不是全部 ( SIGKILL)

是的：我可以unlink()使用第一种方法尽快获得文件，但是如果在和SIGKILL之间收到怎么办？open()unlink()

内核喜欢保证。我也是。无论我的程序何时或如何终止，保证 100% 清理的正确方法是什么。

4

1 回答 1

1

看起来还没有为hugetlbfs 实现O_TMPFILE；事实上，这个选项需要底层文件系统的支持：

O_TMPFILE 需要底层文件系统的支持；只有一部分 Linux 文件系统提供这种支持。在最初的实现中，在 ex2、ext3、ext4、UDF、Minix 和 shmem 文件系统中提供了支持。Linux 3.15 中添加了 XFS 支持。

这可以通过查看在hugetlbfs 中没有inode_ops->tmpfile()实现的内核源代码得到证实。

我相信这里的正确答案是致力于这个实现......

我注意到您对 unlink() 选项的评论，但是，也许以下方法没有那么危险：

  • 使用 TRUNCATE 打开文件（按名称）（因此您可以假设其大小为 0）
  • 取消链接
  • mmap() 它与您的目标大小

如果您的程序在中间被杀死，最坏的情况是留下一个空文件。

于 2016-12-01T16:14:37.190 回答