Add size-gated hugepage optimization for large allocations

[hsane-dev]

Summary

Adds proactive hugepage optimization to improve memory performance for allocations ≥2MB while preserving existing memory management behavior.

Changes

• Modified MmapRegion::Alloc() in system_allocator.h to apply MADV_HUGEPAGE for large allocations
• Added size gating (>= kHugePageSize) to avoid overhead on small allocations
• Preserves existing MADV_NOHUGEPAGE logic for infrequent access patterns

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[toddlipcon]

I could imagine this still causes regressions for some people -- eg if you aren't expecting hugepages and use an arena allocator with a 2MiB allocation size, now you'll get a full 2M RSS whereas before you got granular 4k page allocation as your arena filled up?

[ckennelly]

I think I'm comfortable with someone getting a hugepage: TCMalloc likes hugepages, and manages memory in a hugepage-aware way. We're assuming they're there, even if they aren't, when making allocation decisions.

That said, I'm not sure the size restriction buys us much. Allocations to the system allocator are typically making 1GB-sized allocations, and we end up faulting in the memory later when it HugePageAwareAllocator "backs" it (or more commonly, when it gets to the caller).