使用O_TMPFILE来清理大页面......还是其他方法？

Question

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

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 moint点。 由于以下错误导致失败（出于我无法解释的原因）：

open failed for /dev/hugepages: Operation not supported

为什么呢？更重要的是：我怎样才能保证我的程序使用的所有大页面都被释放？

是的：我可以捕获一些信号（例如SIGTERM）;但不是全部（SIGKILL）

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

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

Answer 1

看起来还没有为hugetlbfs实现O_TMPFILE;实际上，此选项需要支持底层文件系统：

  

O_TMPFILE需要底层文件系统的支持;只有Linux文件系统的一个子集提供该支持。在最初的实现中，ex2，ext3，ext4，UDF，Minix和shmem文件系统提供了支持。添加了XFS支持                 在Linux 3.15中。

通过查看hugetlbfs中没有 inode_ops-＆gt; tmpfile（）实现的内核源代码可以确认这一点。

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

我注意到你对unlink（）选项的评论，但是，以下方法可能没那么危险：

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

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