[BOLT] Fix hugify on new Linux kernels

[maksfb]

Summary

Memory needs to be unlocked before madvise(2) is called for transparent
huge pages. I verified that /proc/<pid>/smaps reports FilePmdMapped
correctly. Note that there's a (non-deterministic) delay before the call
to madvise() is issued and pages are remapped. Thus, it's difficult to
test the functionality automatically.

[yota9]

Could you please provide related kernel commit? Thank you!

[maksfb]

In D140425#4008921, @yota9 wrote:

Could you please provide related kernel commit? Thank you!

There's no corresponding kernel patch. The hugify feature was apparently always broken for THP kernels as pointed out by @treapster in D137620.

[yavtuk]

@maksfb should we lock the memory again after the __madvise?

[maksfb]

In D140425#4009642, @yavtuk wrote:

@maksfb should we lock the memory again after the __madvise?

Sadly, we cannot because of the delayed action of the kernel.

[yota9]

@maksfb I'm just not completely understand why mlock has something todo with it? Why the binary memory even get locked on startup?

[yavtuk]

@maksfb Can you use __prctl(41 /* PR_SET_THP_DISABLE */, 0, 0, 0, 0); call instead of munlock?

[maksfb]

In D140425#4012275, @yavtuk wrote:

@maksfb Can you use __prctl(41 /* PR_SET_THP_DISABLE */, 0, 0, 0, 0); call instead of munlock?

Could not get huge pages on my system with the above.

[maksfb]

In D140425#4010440, @yota9 wrote:

@maksfb I'm just not completely understand why mlock has something todo with it? Why the binary memory even get locked on startup?

I've used the code from HHVM's hugify (https://github.com/facebook/hhvm/blob/62d67f83bd96b23f8522fb1d3fe8597bcfd7fc75/hphp/runtime/base/program-functions.cpp#L859-L863), and huge pages started to work for me. I'm not entirely sure why the memory was locked in the first place.

[yota9]

@maksfb I see, thank you. I assume that the application code becomes locked due to some kind of meta optimisations for the services on the kernel level or interpreter , probably it is not common situation... Because of that I don't really think this munlock call may harm somehow, so LGTM.

bolt/runtime/common.h

int __madvise(void *addr, size_t length, int advice) {
   __asm__ __volatile__("movq $28, %%rax\n"
                        "syscall\n"
                        : "=a"(ret)
                        : "D"(addr), "S"(length), "d"(advice)
                        : "cc", "rcx", "r11", "memory");
   return ret;
 }
 
+int __munlock(void *addr, size_t length) {
+  int ret;
+  __asm__ __volatile__("movq $0x96, %%rax\n"
+                       "syscall\n"
+                       : "=a"(ret)
+                       : "D"(addr), "S"(length)
+                       : "cc", "rcx", "r11", "memory");
+  return ret;
+}
+
 #define _UTSNAME_LENGTH 65
 
 struct UtsNameTy {
   char sysname[_UTSNAME_LENGTH];  /* Operating system name (e.g., "Linux") */
   char nodename[_UTSNAME_LENGTH]; /* Name within "some implementation-defined
                       network" */
   char release[_UTSNAME_LENGTH]; /* Operating system release (e.g., "2.6.28") */
   char version[_UTSNAME_LENGTH]; /* Operating system version */

bolt/runtime/hugify.cpp

extern "C" void __bolt_hugify_self_impl() {
 
   if (!hasPagecacheTHPSupport()) {
     DEBUG(report(
               "[hugify] workaround with memory alignment for kernel < 5.10\n");)
     hugifyForOldKernel(From, To);
     return;
   }
 
+  if (__munlock(From, (To - From)) == -1) {
+    char Msg[] = "[hugify] failed to unlock memory\n";
+    reportError(Msg, sizeof(Msg));
+  }
   if (__madvise(From, (To - From), 14 /* MADV_HUGEPAGE */) == -1) {
     char Msg[] = "[hugify] failed to allocate large page\n";
     // TODO: allow user to control the failure behavior.
     reportError(Msg, sizeof(Msg));
   }
 }
 
 /// This is hooking ELF's entry, it needs to save all machine state.