No way to use `huge(None)` correctly, or other way to default the hugepage size?

[ThomasHabets]

I'm trying to be as flexible as I can, and not hard code the hugepage sizes that x86 provides. It seems that there's no way to use "the default" hugepage size correctly. Am I missing something?

Problems

Drop doesn't work if you don't know the size

The underlying munmap() fails. Here's an example:

mmap(NULL, 112721920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0) = 0x7f2516800000
munmap(0x7f2516800000, 112721920)       = -1 EINVAL (Invalid argument)

Because Drop fails, it's not possible to increase in a loop. It'll memory leak and eventually even the right size will fail.

make_read_only() fails

For the same reason, mprotect() calls fail, since it uses the original length. In theory this should be retryable with exponentially growing length until the hugepage size is hit, but it's risky to blindly fire off such mprotect() calls, so not really an option.

Fixes

App side

I really don't know. Linux provides gethugepagesizes() can be a hint, but memory will still be leaked if you try from smallest to largest. Maybe the app should try from largest to smallest? In any case the app won't be able to use None as .huge() parameter.

memmap-rs side

Or should memmap2-rs read from /proc/self/smaps, and find the map that way, to be able to munmap/mprotect?

[de-vri-es]

Hey, thank you for opening the issue!

The default huge page size can be gotten from the Hugepagesize field of /proc/meminfo.

Generally speaking it would be nice to be able to get them programmatically though. I think a free function to get the default hugepage size (returning None on unsupported OS) would be nice.