我想验证透明的大页面(THP)会导致大的页面错误延迟,因为Linux必须将页面归零,然后才能将它们返回给用户。 THP比4KB页面大512倍,因此清除速度较慢。当内存碎片化时,操作系统通常会压缩内存以生成THP。
所以我想测量次要的页面错误延迟(成本),但我仍然不知道。
答案 0 :(得分:1)
检查https://www.kernel.org/doc/Documentation/vm/transhuge.txt文档并搜索LWN& RedHat为THP延迟和THP故障提供文档。
https://www.kernel.org/doc/Documentation/vm/transhuge.txt说关于零THP:
默认情况下,内核尝试在读取页面错误时使用巨大的零页面 匿名映射。通过写0可以禁用巨大的零页面 或通过写1:
启用它echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
您可以改变设置(在2012年左右推出:https://lwn.net/Articles/517465/添加一个巨大的零页面)并测量页面映射和访问延迟。只需用rdtsc / rdtscp / CLOCK_MONOTONIC读取一些系统时间,就可以访问页面,重读时间;记录时差的统计数据,如min / max / avg;绘制直方图 - 计算在0..100,101..300,301..600 ......范围内有多少差异以及有多少差异大于某个巨大值。计算直方图的数组很小。
您可以尝试使用MAP_POPULATE
标记的mmap() - (http://d3s.mff.cuni.cz/teaching/advanced_operating_systems/slides/10_huge_pages.pdf第17页)
RedHat博客发布了有关THP& amp;页面错误延迟(借助其固定的SystemTap跟踪):https://developers.redhat.com/blog/2014/03/10/examining-huge-pages-or-transparent-huge-pages-performance/
为了防止信息从页面的前一个用户泄漏,内核在整个页面中写入零。对于4096字节的页面,这是一个相对较短的操作,只需要几微秒。 x86 largepages大小为2MB,比普通页面大512倍。因此,操作可能需要数百微秒并影响延迟敏感代码的操作。下面是一个简单的SystemTap命令行脚本,用于显示哪些应用程序将大页面清零以及这些操作需要多长时间。它将一直运行直到按下cntl-c。
stap -e 'global huge_clear probe kernel.function("clear_huge_page").return { huge_clear [execname(), pid()] <<< (gettimeofday_us() - @entry(gettimeofday_us()))}'
另外,我不确定这一点,但从理论上讲,Linux Kernel可能会有一些内核线程在任何应用程序需要它们之前对大页面进行预置。