2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
16KB 페이지 크기
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
페이지 크기는 OS가 메모리를 관리하는 세부사항입니다. 오늘날 대부분의 CPU는 4KB 페이지 크기를 지원하므로 Android OS와 앱은 4KB 페이지 크기로 실행되도록 빌드되고 최적화되었습니다. ARM CPU는 더 큰 16KB 페이지 크기를 지원하며 Android 15부터 AOSP는 16KB 페이지 크기로 Android를 빌드하는 것도 지원합니다. 이 옵션은 추가 메모리를 사용하지만 시스템 성능을 향상시킵니다. Android 15부터 이 옵션은 기본적으로 사용 설정되어 있지 않지만 OEM과 앱 개발자가 향후 모든 곳에서 16KB 모드로 전환할 수 있도록 개발자 모드 또는 개발자 옵션으로 제공됩니다.
Android 15 이상에서는 16KB ELF 정렬로 Android를 빌드하는 것을 지원하며, 이는 android14-6.1부터 시작하는 4KB 및 16KB 커널과 함께 작동합니다.
16KB 커널과 함께 사용하면 이 구성은 추가 메모리를 사용하지만 시스템 성능을 향상시킵니다.
Android를 16KB로 설정
16KB 페이지는 16KB 커널이 있는 arm64 타겟에서만 지원됩니다.
그러나 Cuttlefish에서 사용할 수 있는 x86_64의 16KB 사용자 공간 시뮬레이션 옵션도 있습니다.
커널 공간
arm64 타겟의 경우 Kleaf를 사용하여 커널을 빌드하면 --page_size=16k가 16KB 모드로 커널을 빌드합니다.
Linux 커널 구성을 직접 사용하는 경우 CONFIG_ARM64_4K_PAGES 대신 CONFIG_ARM64_16K_PAGES를 설정하여 16KB 페이지를 선택할 수 있습니다.
사용자 공간
Android 사용자 공간에서 16KB 페이지 크기 지원을 사용 설정하려면 제품에서 다음 빌드 옵션을 설정하세요.
PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true는 PAGE_SIZE 정의를 삭제하며, 구성 요소가 런타임에 페이지 크기를 결정하도록 합니다.PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384는 플랫폼 ELF 파일이 16KB 정렬로 빌드되도록 합니다. 필요 이상으로 큰 크기는 향후의 호환성을 고려한 것입니다. 16KB ELF 정렬을 사용하면 커널이 4KB/16KB 페이지 크기를 지원할 수 있습니다.
빌드 플래그 확인
lunch 타겟을 선택한 후 다음과 같이 빌드 플래그가 환경에서 올바르게 설정되어 있는지 확인하세요.
$ source build/envsetup.sh
$ lunch target
$ get_build_var TARGET_MAX_PAGE_SIZE_SUPPORTED
16384
$ get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO
true
이전 명령어 두 개에서 각각 16384과 true가 반환되면 16KB 커널과 함께 작동하도록 빌드 플래그가 올바르게 설정된 것입니다. 하지만 빌드가 통과되더라도 16KB 환경의 차이로 인해 런타임 문제가 발생할 수 있습니다.
16KB 페이지 크기 시스템 프로그래밍
Android 기반 기기의 대부분의 코드는 페이지 크기를 직접 처리하지 않습니다. 하지만 페이지를 처리하는 코드의 경우 커널의 메모리 할당 동작이 변경되므로 호환될 뿐만 아니라 성능이 최대한 높고 리소스 집약도가 최소인 코드를 작성할 때 이를 염두에 두어야 합니다.
4KB 시스템에서 1KB, 2KB 또는 최대 4KB 영역에서 mmap를 호출하면 시스템에서 이를 구현하기 위해 4KB를 예약합니다. 즉, 커널에서 메모리를 요청할 때 커널은 항상 요청된 메모리를 가장 가까운 페이지 크기로 올림해야 합니다. 예를 들어 4KB 영역에 5KB 영역을 할당하면 커널은 8KB를 할당합니다.
16KB 커널에서는 이러한 페이지의 추가 '꼬리 끝'이 더 큽니다.
예를 들어 1KB부터 5KB까지의 이러한 할당은 모두 16KB 커널과 함께 사용하면 16KB를 할당합니다. 17KB를 요청하면 32KB가 할당됩니다.
예를 들어 4KB 시스템에서는 4KB 읽기-쓰기 익명 리전을 두 개 할당해도 됩니다. 하지만 16KB 커널에서는 페이지 두 개 또는 32KB가 할당됩니다. 16KB 커널에서는 가능하면 이러한 리전을 단일 읽기 또는 쓰기 가능 페이지로 결합하여 16KB만 사용할 수 있으므로 4KB 커널 사례에 비해 8KB가 낭비됩니다. 메모리 사용량을 더 줄이려면 페이지를 더 많이 결합하면 됩니다. 실제로 최대한 최적화된 16KB 시스템에서는 페이지 테이블이 동일한 메모리에 대해 1/4 크기이므로 16KB 페이지에 4KB 시스템보다 적은 메모리가 필요합니다.
mmap를 사용할 때는 요청하는 크기를 가장 가까운 페이지 크기로 올림해야 합니다. 이렇게 하면 커널에서 할당하는 전체 메모리 양이 암시적으로 요청되고 암시적으로 또는 실수로 액세스되는 대신 런타임 값에서 사용자 공간에 직접 표시됩니다.
16KB ELF 정렬로 공유 라이브러리 빌드
Android 프로젝트에 포함된 공유 라이브러리를 빌드하려면 16KB 페이지 크기 사용 설정의 이전 설정으로 충분합니다.
PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := truePRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384
Android 프로젝트에 포함되지 않은 공유 라이브러리를 빌드하려면 다음 링커 플래그를 전달해야 합니다.
-Wl,-z,max-page-size=16384
16KB ELF 정렬의 바이너리 및 사전 빌드 확인
정렬 및 런타임 동작을 확인하는 가장 좋은 방법은 16KB로 컴파일된 커널에서 테스트하고 실행하는 것입니다. 하지만 일부 문제를 더 일찍 포착하려면 다음 단계를 따르세요.
Android 16부터 빌드 시간에 PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true를 설정할 수 있습니다. Android.bp에서 ignore_max_page_size: true을 사용하고 Android.mk에서 LOCAL_IGNORE_MAX_PAGE_SIZE := true을 사용하여 일시적으로 무시합니다. 이러한 설정은 모든 사전 빌드를 확인하고 사전 빌드가 업데이트되었지만 16KB로 정렬되지 않은 경우를 감지할 수 있도록 합니다.
Android 15 이상으로 출시되는 기기에서 온디바이스 ELF 파일의 정렬을 확인하는 atest elf_alignment_test를 실행할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-08-17(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-17(UTC)"],[],[],null,["# 16 KB page size\n\nPage size is the granularity at which an OS manages memory. Most CPUs today\nsupport a 4 KB page size and so the Android OS and apps have\nhistorically been built and optimized to run with a 4 KB page size. ARM\nCPUs support the larger 16 KB page size, and starting in Android\n15, AOSP has support for building Android with a\n16 KB page size as well. This option uses additional memory but improves\nsystem performance. As of Android 15, this option isn't\nenabled by default, but it is available as a developer mode or a developer\noption for OEMs and app developers to prepare for switching to 16 KB mode\neverywhere in the future.\n\nAndroid 15 and higher have support for building\nAndroid with a 16 KB ELF alignment, which works with 4 KB and\n16 KB kernels starting with\n[`android14-6.1`](https://android.googlesource.com/kernel/common/+/refs/heads/android14-6.1).\nWhen used with a 16 KB kernel, this configuration uses additional memory\nbut improves system performance.\n\nSet Android to 16 KB\n--------------------\n\n16 KB pages are only supported on `arm64` targets with 16 KB kernels.\nHowever, there is also an option to\n[simulate 16 KB userspace on `x86_64`](/docs/core/architecture/16kb-page-size/getting-started-cf-x86-64-pgagnostic) for Cuttlefish.\n\n### Kernel space\n\nFor `arm64` targets, if you use\n[Kleaf](https://android.googlesource.com/kernel/build/+/refs/heads/main/kleaf/docs/kleaf.md)\nto build your kernel, `--page_size=16k` builds the kernel in 16 KB mode.\nIf you are directly using Linux kernel configuration, you can select 16 KB\npages by setting `CONFIG_ARM64_16K_PAGES` instead of `CONFIG_ARM64_4K_PAGES`.\n\n### User space\n\nTo enable 16 KB page size support in Android user space, set the following\nbuild options on your product:\n\n- `PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true` removes the `PAGE_SIZE` define, and it makes components determine page size at runtime.\n- `PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384` which ensures platform ELF files are built with 16 KB alignment. This larger-than-needed size is for future compatibility. With 16 KB ELF alignment, the kernel can support 4 KB/16 KB page sizes.\n\nVerify build flags\n------------------\n\nAfter selecting the `lunch` target, verify that the build flags are set up\ncorrectly in the environment: \n\n $ source build/envsetup.sh\n $ lunch \u003cvar translate=\"no\"\u003etarget\u003c/var\u003e\n\n $ get_build_var TARGET_MAX_PAGE_SIZE_SUPPORTED\n 16384\n $ get_build_var TARGET_NO_BIONIC_PAGE_SIZE_MACRO\n true\n\nIf the previous two commands return `16384` and `true` respectively, your build\nflags are set up correctly to work with a 16 KB kernel. However, even if\na build passes, there might still be runtime issues due to differences in a\n16 KB environment.\n\n16 KB page size system programming\n----------------------------------\n\nThe vast majority of code on any Android-powered device doesn't directly deal\nwith page size. However, for code that deals with pages, the kernel's memory\nallocation behavior changes, and you need to keep this in mind to write code\nthat is not only compatible but also maximally performant and minimally\nresource intensive.\n\nIf you call `mmap` on a 1 KB, 2 KB, or up to a 4 KB region on a\n4 KB system, the system reserves 4 KB to implement this. In other\nwords, when requesting memory from the kernel, the kernel must always round up\nthe requested memory to the nearest page size. For example, if you allocate a\n5 KB region on a 4 KB region, the kernel allocates 8 KB.\n\nOn a 16 KB kernel, these extra \"tail ends\" of pages are larger.\nFor example, all of these allocations, from 1 KB to 5 KB would\nallocate 16 KB when used with a 16 KB kernel. If you request\n17 KB, it allocates 32 KB.\n\nFor example, on a 4 KB system, it's okay to allocate two 4 KB\nread-write anonymous regions. However, on a 16 KB kernel, this would result\nin allocating two pages or 32 KB. On a 16 KB kernel, if possible,\nthese regions can be combined into a single read or writeable page so that only\n16 KB is used, wasting 8 KB compared to the 4 KB kernel case. To\nreduce even more memory usage, more pages can be combined. In fact, on a\n16 KB system that is maximally optimized, 16 KB pages require less\nmemory than 4 KB systems because the page table is one fourth the size\nfor the same memory.\n\nWhenever using `mmap`, ensure that you round the size you are requesting up to\nthe nearest page size. This ensures that the entire amount of memory the kernel\nallocates is directly visible to userspace in runtime values, instead of being\nimplicitly requested and implicitly or accidentally accessible.\n\nBuild shared libraries with 16 KB ELF alignment\n-----------------------------------------------\n\nTo build shared libraries that are part of the\n[android project](https://cs.android.com/android/platform/superproject/main),\nthe earlier settings in [Enable 16 KB page size](#enable-16kb) are sufficient:\n\n- `PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true`\n- `PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384`\n\nTo build shared libraries that aren't part of\n[android project](https://cs.android.com/android/platform/superproject/main),\nyou need to pass this linker flag: \n\n -Wl,-z,max-page-size=16384\n\nVerify binaries and prebuilts for 16 KB ELF alignment\n-----------------------------------------------------\n\nThe best way to verify alignment and runtime behavior is to test and run on a\n16 KB compiled kernel. However, in order to catch some issues earlier:\n\n- Starting in Android 16, you can set\n `PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true` at build time. Use\n `ignore_max_page_size: true` in `Android.bp` and\n `LOCAL_IGNORE_MAX_PAGE_SIZE := true` in `Android.mk` to temporarily ignore\n them. These settings verify all prebuilts and allow you to detect when one\n is updated but is not 16 KB aligned.\n\n- You can run `atest elf_alignment_test` which verifies the alignment of\n on-device ELF files on devices launching with\n Android 15 and later."]]
