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% 증가한 것도 큰 수치로 보임
  • 메모리 사용량에 미친 영향이 궁금함