On Linux and Chrome OS, I get:

$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

According to https://linux.die.net/man/2/madvise:

"""
MADV_HUGEPAGE (since Linux 2.6.38)
Enables Transparent Huge Pages (THP) for pages in the range specified by addr and length. Currently, Transparent Huge Pages only work with private anonymous pages (see mmap(2)). The kernel will regularly scan the areas marked as huge page candidates to replace them with huge pages. The kernel will also allocate huge pages directly when the region is naturally aligned to the huge page size (see posix_memalign(2)).
"""

I think that's the `always` behavior; when the setting is `madvise`, you only get hugepages with `madvise(address, size, MADV_HUGEPAGE)`.

So it seems that we have already turned off hugepages on Linux and Chrome OS. We call madvise with `MADV_HUGEPAGE` in only 1 place (chromeos/hugepage_text/hugepage_text.cc).

On Android, /sys/kernel/mm/transparent_hugepage/enabled seems not to exist. What that means for hugepages, I don't yet know.

Toon says: "On the other hand, I get a clear cache timing signal on OSX with a configuration that should only work if typed arrays aligned on physical pages... so at least on some operating systems that's the default behavior?" macOS has `VM_FLAGS_SUPERPAGE_SIZE_*` (https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/mmap.2.html) for what looks like equivalent behavior. But it may be on by default, unlike our Linuxes? +erikchen who might know. We never explicitly use `VM_FLAGS_SUPERPAGE_SIZE_*`.

+wfh: Do you know of an equivalent behavior on Windows?

Chrome is not allocating superpages on macOS. It is also not intentionally allocating contiguous physical memory. 

Observations:
1) Trying to allocate superpages is very hard on a long-running instance of macOS. I actually couldn't get a test program to do this without restarting the machine [the kernel couldn't get a 2MB contiguous region]

2) After a restart, there were no issues. The share_mode of the memory region is SM_LARGEPAGE, which vmmap reports as "SM=". Using vmmap on Chrome processes reveals no VM_ALLOCATE regions with "SM="

3) Looking at the source itself, the only way to allocate superpages is with mmap or vm_allocate w/ appropriate flags. Chrome does not do this.

4) In the kernel, the function responsible for allocating contiguous physical memory is cpm_allocate(). There are a small number of consumers of this function, but those don't appear to be called by Chrome.

5) But it's possible that the pages are contiguous for less obvious reasons. Two possibilities:
  5a) physical pages get placed in some queue contiguously. When we mmap a large reason and start touching the pages, the kernel just starts dequeuing pages contiguously, thus resulting in a contiguous region.
  5b) The implementation of page-faulting is being clever and intentionally makes the physical pages contiguous. 

I went through the faulting implementation vm_fault_enter() and didn't see any clever logic. We should be able to verify (5a). Write a program that uses vmmap to allocate all the physical memory in small chunks. Then release them in a random order. Then see if the cache timing signal still works.

I think there is nothing more to do here.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot