According to the architecture overview document Aarch64 supports 4k and 64k pages. Some CPUs also support 16k pages. Looking into address translation scheme details I come to the conclusion that such CPUs don't support the simultaneous existence of different-sized pages (unlike x86_64 which allows that). Am I right?
You're conflating two different, albeit related, things here - page size vs. granularity.
In AArch64, you have 3 possible translation granules to choose from, each of which results in a different set of page sizes:
- 4KB granule: 4KB, 2MB, and 1GB pages.
- 16KB granule: 16KB and 32MB pages.
- 64KB granule: 64KB and 512MB pages.
The translation granule defines various properties of the translation regime in general, so it applies to a whole set of tables and you are correct in the sense that you can't mix and match granules within a table, although it's perfectly fine to use different granules for different tables at the same time (e.g. at different exception levels).
Comparatively, x86 always has 4KB granularity, but the range of page sizes on offer varies depending on the mode:
- 32-bit: 4KB and 4MB pages.
- PAE: 4KB and 2MB pages.
- 64-bit: 4KB, 2MB, and (if supported) 1GB pages.
In both cases, the page sizes larger than the basic granule represent block entries at intermediate table levels. In other words, using the common 4KB granule, 3-level*, example:
- Each valid entry in the first-level table points to either a naturally-aligned 1GB region of memory, or a second-level table describing that 1GB of address space.
- Each valid entry in a second-level table points to either a naturally-aligned 2MB region of memory, or a third-level table describing that 2MB of address space.
- Each valid entry in a third-level table points to a naturally-aligned 4KB region of memory.
* Depending on the actual address space size, there may be a zero'th-level table above this, but neither architecture allows block entries at that level (they would be impractically huge anyway). For AArch64 the larger granules only support block/page entries at level 2 and 3, and the 64KB granule never has a level 0 at all.
looks, it is possible on Raspberry Pi 4B (aarch64) with 64-Bit OS (Ubuntu 22.04) .. but the number of huge pages has to be reserved or allocated as root beforehand:
echo "256" |sudo tee /proc/sys/vm/nr_hugepages
or permanently
sudo sysctl -w vm.nr_hugepages=256
replace the 256
with the required maximum amount of huge pages, each with size of
grep Hugepagesize: /proc/meminfo
i get 2048 kB or 2 MBytes for huge pages and 4 kB for normal pages with getconf PAGE_SIZE
.
now, an mmap()
with the MAP_HUGETLB
flag is accepted from a C program.
found this at Why mmap cannot allocate memory? when looking for a solution myself.
© 2022 - 2024 — McMap. All rights reserved.