▲

GN⁺: Android에 16kb 페이지 크기 추가

 (android-developers.googleblog.com)
10P by neo 3달전 | favorite | 댓글 2개
  • 페이지는 운영 체제가 메모리를 관리하는 최소 단위
  • 대부분의 CPU는 4 KB 페이지 크기를 지원하며, Android OS와 애플리케이션은 4 KB 페이지 크기에 최적화되어 있음
  • ARM CPU는 16 KB 페이지 크기를 지원하며, Android가 이 크기를 사용할 때 성능이 5-10% 향상되고 메모리 사용량은 약 9% 증가함
  • 전반적인 운영 체제 성능을 개선하고 기기 제조업체가 이러한 트레이드오프를 선택할 수 있도록 Android 15는 4 KB 또는 16 KB 페이지 크기로 실행 가능함
  • 16 KB 페이지 크기를 지원하는 첫 Android 시스템은 몇몇 기기에서 개발자 옵션으로 제공될 예정임

16KB 페이지 크기에 대한 기술적 세부 사항

  • 대부분의 CPU에는 메모리 관리 장치(MMU)라는 전용 하드웨어가 있어 프로그램이 사용 중인 주소를 메모리의 물리적 위치로 변환
  • 이 변환은 페이지 크기 단위로 수행됨
    • 프로그램이 더 많은 메모리가 필요할 때마다 운영 체제가 개입하여 "페이지 테이블" 항목을 채워야 하며, 해당 메모리 조각을 프로세스에 할당
  • 페이지 크기가 4배 더 커지면 장부 기록 작업이 4배 줄어듬.
    • 따라서 시스템은 비디오를 멋지게 보이게 하고, 게임을 잘 플레이하고, 앱을 매끄럽게 실행하는 데 더 많은 시간을 할애할 수 있으며, 낮은 수준의 운영 체제 문서 작업에는 더 적은 시간이 소요됨
  • 페이지 크기는 Application Binary Interface (ABI)가 아님
  • 즉, 애플리케이션이 페이지 크기에 구애받지 않도록 수정되면 동일한 애플리케이션 바이너리가 4KB와 16KB 디바이스 모두에서 실행될 수 있음
  • Android 15에서는 다양한 페이지 크기에서 실행할 수 있도록 Android를 처음부터 리팩토링하여 페이지 크기에 구애받지 않도록 만듦

주요 OS 변경 사항

  • Android 15 기반 장치:
    • 컴파일 타임 PAGE_SIZE 매크로가 런타임 getpagesize(2)로 대체됨
    • 모든 OS 바이너리는 16 KB 정렬됨 (서드 파티 애플리케이션/라이브러리는 16KB 정렬되지 않을 수 있음)
    • 모든 OS 바이너리는 프로세스에 매핑된 모든 메모리 영역을 읽을 수 있도록 별도의 로드 가능한 세그먼트로 빌드되며, 일부 애플리케이션은 이에 의존함
    • 여러 OS 구성 요소가 페이지 크기를 가정하지 않고 더 큰 페이지 크기에 대해 최적화되도록 재작성됨

파일 시스템

  • 성능 좋은 작업을 위해서는 파일 시스템 블록 크기가 페이지 크기와 일치해야 함. EROFS 및 F2FS 파일 시스템과 UFS 스토리지 계층이 16KB 호환됨
  • 4KB 시스템에서는 16KB 정렬을 위해 추가된 패딩으로 인해 ELF 실행 파일 크기가 증가하지만 여러 최적화를 통해 이 비용을 회피함
  • Sparse 읽기 전용 파일 시스템은 16KB 정렬을 위한 추가 패딩에 대해 생성된 0 페이지가 디스크에 기록되지 않도록 함
  • 읽기/쓰기 가능 파일 시스템은 0 페이지를 케이스별로 처리함

메모리 관리

  • 리눅스 페이지 캐시가 수정되어 이러한 여분의 패딩 공간에 대해 미리 읽지 않도록 하여 불필요한 메모리 로드를 절약
  • 이 페이지는 비어있는 패딩이며 프로그램은 절대 이를 읽지 않음. 정렬 목적으로만 프로그램의 사용 가능한 부분 사이에 있는 공간임

Linux 커널

  • 리눅스 커널은 특정 페이지 크기에 깊이 연결되어 있으므로 커널을 빌드할 때 사용할 페이지 크기를 선택해야 하며, 운영 체제의 나머지 부분은 동일하게 유지됨

Android 애플리케이션

  • 네이티브 코드 또는 의존성이 있는 모든 애플리케이션은 16KB 페이지 크기 디바이스와 호환되도록 다시 컴파일해야 함
  • 대부분의 Android 애플리케이션 및 SDK 내의 네이티브 코드는 4KB 페이지 크기를 염두에 두고 빌드되었기 때문에 16KB로 다시 정렬하여 바이너리가 4KB 및 16KB 디바이스와 모두 호환되도록 해야 함
  • 대부분의 애플리케이션 및 SDK에서 이는 2단계 프로세스임:
    1. 16KB 정렬로 네이티브 코드 재빌드
    2. 페이지 크기에 대한 하드코딩된 가정이 있는 경우 16KB 디바이스/에뮬레이터에서 테스트 및 수정

16 KB 장치 개발하기

  • 현재 생산되는 Android 기기는 16 KB 페이지 크기를 지원하지 않음
    • 이 문제를 해결하기 위해 파트너와 협력하여 기존 기기에서 개발자 옵션을 사용할 수 있도록 조치를 취하고 있
  • 개발자 옵션으로 16 KB 페이지 크기 지원을 제공할 예정임
  • Android Studio에서 16 KB 에뮬레이터 타겟을 사용할 수 있음

16 KB 개발자 옵션

  • Android 15에서 16 KB와 4 KB 페이지 크기를 전환할 수 있는 개발자 옵션을 구현함
  • Pixel 8 및 Pixel 8 Pro에서 사용 가능하며, 추가 장치에서도 지원 예정임
  • 개발자 옵션을 사용하려면 장치를 초기화하고 부트로더를 언락해야 함

x86_64 데스크탑에서 16 KB

  • x86_64 에뮬레이터에서 16 KB 페이지 크기를 에뮬레이트할 수 있음
  • Android Studio SDK 매니저에서 16 KB 페이지 에뮬레이터를 다운로드하고 실행할 수 있음

미래

  • Android 15와 AOSP는 16 KB 페이지를 지원하며, 개발자 옵션으로 구현 가능함
  • 애플리케이션 및 SDK 개발자가 이 옵션을 활용하여 더 성능 좋고 효율적인 Android 장치를 준비할 수 있기를 기대함

GN⁺의 의견

  • 16KB 페이지 크기로의 전환은 Android 디바이스의 성능과 효율성을 향상시키기 위한 중요한 변화
  • 더 큰 페이지 크기를 사용하면 메모리 관리 오버헤드가 감소하고 전반적인 시스템 성능이 향상될 수 있음
  • 그러나 이 변화는 특히 네이티브 코드에 의존하는 앱 및 SDK에 대한 호환성 문제를 초래할 수도 있으므로 개발자는 16KB 페이지 크기를 염두에 두고 소프트웨어를 업데이트해야 함
  • Google은 16KB 개발자 옵션 및 에뮬레이터 지원을 통해 이 전환을 테스트하고 준비할 수 있는 도구를 개발자에게 제공하고 있음
  • 16KB 페이지는 현재 ARM 기반 Android 디바이스에만 적용되지만, 미래에는 다른 하드웨어 플랫폼으로 확장될 가능성이 있음
  • 개발자는 앱과 SDK를 16KB 페이지 크기에 맞게 조정하는 것 외에도, 더 큰 페이지 크기가 메모리 사용량에 미치는 영향을 고려하고 필요한 경우 메모리 최적화를 수행해야 함
  • 16KB 페이지로의 전환은 Android 생태계 전반에 걸친 협력이 필요한 중요한 노력이지만, 결국 사용자에게 더 나은 성능과 효율성을 제공할 것임
▲
neo 3달전  [-]
Hacker News 의견

  • Debian 커널에서 ARM64 커널을 16KiB 페이지 크기로 빌드하는 작업을 최근에 시작했음

    • 64KiB 페이지 크기도 추가 논의 중
    • Apple M1의 DART IOMMU가 최소 16KiB 페이지 크기를 요구하여 효율성 증가 예상

  • 첫 번째 16KB 지원 Android 시스템이 개발자 옵션으로 일부 기기에서 제공될 예정임

    • 개발자 옵션을 통해 테스트 및 수정 가능
    • 페이지 크기에 무관한 애플리케이션 바이너리는 4KB와 16KB 기기에서 모두 실행 가능

  • 애플리케이션이 페이지 크기에 무관하지 않을 때가 궁금함

    • 어떤 상황에서 이 문제가 발생하는지 알고 싶음

  • 4KB와 16KB 프로세스를 동시에 지원하지 않고 16KB 기본값을 사용하는 것은 문제가 있음

    • 오래된 바이너리가 깨지고 에뮬레이터 성능 저하 우려
    • 4KB 페이지도 지원하는 커널이 필요함
    • CPU 설계에서 16KB 페이지 테이블 항목을 4KB 단위로 매핑할 수 있도록 하는 것이 합리적일 것임

  • iOS는 64비트 전환 이후 16KB 페이지를 사용해왔음

    • ARM Mac도 이 설계를 계승함

  • RHEL은 과거에 AARCH64에서 64KB 페이지를 시도했으나 많은 버그로 인해 결국 되돌림

    • Google의 노력은 인상적이나 성공할지는 의문임

  • Asahi가 16KB 페이지를 활성화하는 커널 및 생태계 작업에 얼마나 도움을 주었는지 궁금함

    • RISC-V가 4KB 페이지로 고정된 것은 실수로 보임

  • iOS는 오래전부터 16K 페이지를 사용해왔음

    • OSX는 M1과 함께 2020년에 16K 페이지로 전환함
    • Windows는 AArch64에서도 4K 페이지에 머물러 있음
    • Linux는 다양한 페이지 크기를 지원함. Asahi는 16K임

  • 페이지 크기 증가가 I/O 성능이나 플래시 수명에 부정적인 영향을 미치는지 궁금함

    • 현대의 관리형 플래시 장치의 쓰기 단위가 4KB나 16KB보다 큰지 여부도 궁금함

  • 성능 개선이 측정되었음

    • 특히 카메라 앱이 더 빨리 시작됨
    • 다른 최적화 가능성에 대해 궁금함
    • Lisp의 "이미지 덤프"와 같은 방식으로 초기화 코드를 최소화할 수 있을지 궁금함

  • 5-10% 성능 향상이 큰 수치로 보임

    • 페이지 워크가 그렇게 비싸다면 더 큰 TLB가 있어야 하지 않나 궁금함
    • 메모리 사용량이 9% 증가한 것도 큰 수치로 보임
    • 메모리 사용량에 미친 영향이 궁금함
답변달기
▲
gurugio 3달전  [-]
  • 최신 스토리지들은 IO가 스토리지 내부의 캐시에 저장되기때문에 16KB로 IO가 발생해도 별다른 차이가 없을걸로 예상됩니다.
  • 카메라, GPU등 성능이 중요해서 연속된 페이지를 할당받는 장치들의 성능으 개선됩니다.
  • TLB는 하드웨어 캐시라서 비용이 문제될거같습니다.
  • 메모리 사용량이 10%증가하는 것은 최신 모델들의 메모리 크기에 비해 별 문제가 되지 않는다고 판단하는 걸로 보입니다.
  • 4k/16k를 동시에 지원하는건 CPU 코어부터 커널 코어 부분을 수정해야되서 저는 거의 불가능하다고 생각합니다. 커널이 hugepage등으로 큰 페이지 기능을 오래동안 활용해왔으니 16k동작은 별 문제가 없을거라고 생각합니다. 커널 외에 안드로이드의 기능들이나 앱에서 문제가 생기는 것은 구글에서 관리해야겠지요.
  • 어쨌든 64비트 코어에 점점 메모리가 커지는 상황에서 페이지 사이즈를 늘리는 것은 서버 시장에서 이미 예전부터 논의가 되고 있었습니다. 스마트폰도 이제 불가피하게 적용해야될걸로 생각합니다.
답변달기