Bổ sung kích thước trang 16 KB cho Android

• Trang là đơn vị tối thiểu mà hệ điều hành dùng để quản lý bộ nhớ
• Hầu hết CPU hỗ trợ kích thước trang 4 KB, và Android OS cùng các ứng dụng đã được tối ưu cho kích thước trang 4 KB
• CPU ARM hỗ trợ kích thước trang 16 KB, và khi Android sử dụng kích thước này thì hiệu năng tăng 5-10% trong khi mức sử dụng bộ nhớ tăng khoảng 9%
• Để cải thiện hiệu năng tổng thể của hệ điều hành và cho phép nhà sản xuất thiết bị lựa chọn sự đánh đổi này, Android 15 có thể chạy với kích thước trang 4 KB hoặc 16 KB
• Hệ thống Android đầu tiên hỗ trợ kích thước trang 16 KB sẽ được cung cấp dưới dạng tùy chọn nhà phát triển trên một số thiết bị

Chi tiết kỹ thuật về kích thước trang 16KB

• Hầu hết CPU đều có phần cứng chuyên dụng gọi là bộ quản lý bộ nhớ (MMU) để chuyển đổi địa chỉ mà chương trình đang sử dụng sang vị trí vật lý trong bộ nhớ
• Việc chuyển đổi này được thực hiện theo đơn vị kích thước trang
  • Mỗi khi chương trình cần thêm bộ nhớ, hệ điều hành phải can thiệp để điền mục trong "bảng trang" và cấp phát phần bộ nhớ đó cho tiến trình
• Nếu kích thước trang lớn hơn 4 lần thì công việc ghi chép sổ sách sẽ giảm đi 4 lần.
  • Nhờ đó, hệ thống có thể dành nhiều thời gian hơn để hiển thị video đẹp mắt, chơi game tốt hơn và chạy ứng dụng mượt mà hơn, đồng thời tốn ít thời gian hơn cho công việc giấy tờ ở tầng thấp của hệ điều hành
• Kích thước trang không phải là Application Binary Interface (ABI)
• Nói cách khác, nếu ứng dụng được chỉnh sửa để không phụ thuộc vào kích thước trang thì cùng một binary ứng dụng có thể chạy trên cả thiết bị 4KB và 16KB
• Trong Android 15, Android đã được refactor từ đầu để không phụ thuộc vào kích thước trang, giúp có thể chạy trên nhiều kích thước trang khác nhau

Các thay đổi chính của OS

• Thiết bị dựa trên Android 15:
  • Macro PAGE_SIZE tại thời điểm biên dịch được thay bằng getpagesize(2) tại thời gian chạy
  • Mọi binary của OS đều được căn hàng 16 KB (ứng dụng/thư viện bên thứ ba có thể chưa được căn hàng 16KB)
  • Mọi binary của OS được build với một segment có thể nạp riêng để có thể đọc mọi vùng bộ nhớ được map vào tiến trình, và một số ứng dụng phụ thuộc vào điều này
  • Nhiều thành phần của OS đã được viết lại để không giả định kích thước trang và được tối ưu cho kích thước trang lớn hơn

Hệ thống tệp

• Để đạt hiệu năng tốt, kích thước block của hệ thống tệp phải khớp với kích thước trang. Hệ thống tệp EROFS và F2FS cùng tầng lưu trữ UFS đều tương thích với 16KB
• Trên hệ thống 4KB, kích thước file thực thi ELF tăng lên do phần đệm thêm vào để căn hàng 16KB, nhưng nhiều tối ưu hóa giúp tránh được chi phí này
• Hệ thống tệp chỉ đọc sparse bảo đảm các trang 0 được tạo ra do phần đệm bổ sung cho căn hàng 16KB không bị ghi xuống đĩa
• Hệ thống tệp có thể đọc/ghi xử lý các trang 0 theo từng trường hợp

Quản lý bộ nhớ

• Linux page cache đã được sửa để không đọc trước phần không gian đệm dư thừa này, giúp tránh tải bộ nhớ không cần thiết
• Những trang này là phần đệm trống và chương trình sẽ không bao giờ đọc chúng. Đây chỉ là không gian nằm giữa các phần có thể sử dụng của chương trình nhằm mục đích căn hàng

Linux kernel

• Linux kernel gắn chặt với một kích thước trang cụ thể, vì vậy phải chọn kích thước trang sẽ dùng khi build kernel, còn phần còn lại của hệ điều hành có thể giữ nguyên

Ứng dụng Android

• Mọi ứng dụng có native code hoặc dependency đều phải được biên dịch lại để tương thích với thiết bị có kích thước trang 16KB
• Vì native code trong phần lớn ứng dụng Android và SDK được build với giả định kích thước trang 4KB, nên cần căn hàng lại sang 16KB để binary tương thích với cả thiết bị 4KB lẫn 16KB
• Với phần lớn ứng dụng và SDK, đây là quy trình 2 bước:
  1. Build lại native code với căn hàng 16KB
  2. Nếu có giả định hardcode về kích thước trang, hãy kiểm thử và sửa trên thiết bị/emulator 16KB

Phát triển cho thiết bị 16 KB

• Hiện nay các thiết bị Android đang được sản xuất chưa hỗ trợ kích thước trang 16 KB
  • Để giải quyết vấn đề này, Google đang phối hợp với các đối tác để cho phép sử dụng tùy chọn nhà phát triển trên các thiết bị hiện có
• Sẽ cung cấp hỗ trợ kích thước trang 16 KB dưới dạng tùy chọn nhà phát triển
• Có thể sử dụng target emulator 16 KB trong Android Studio

Tùy chọn nhà phát triển 16 KB

• Trong Android 15, đã triển khai tùy chọn nhà phát triển cho phép chuyển đổi giữa kích thước trang 16 KB và 4 KB
• Có sẵn trên Pixel 8 và Pixel 8 Pro, và sẽ hỗ trợ thêm trên các thiết bị khác
• Để sử dụng tùy chọn nhà phát triển, cần khôi phục thiết bị và mở khóa bootloader

16 KB trên desktop x86_64

• Có thể mô phỏng kích thước trang 16 KB trên x86_64 emulator
• Có thể tải xuống và chạy emulator trang 16 KB trong Android Studio SDK Manager

Tương lai

• Android 15 và AOSP hỗ trợ trang 16 KB, và có thể triển khai qua tùy chọn nhà phát triển
• Hy vọng các nhà phát triển ứng dụng và SDK sẽ tận dụng tùy chọn này để chuẩn bị cho các thiết bị Android hiệu năng cao và hiệu quả hơn

Ý kiến của GN⁺

• Việc chuyển sang kích thước trang 16KB là một thay đổi quan trọng nhằm cải thiện hiệu năng và hiệu quả của thiết bị Android
• Sử dụng kích thước trang lớn hơn có thể làm giảm overhead quản lý bộ nhớ và cải thiện hiệu năng tổng thể của hệ thống
• Tuy nhiên, thay đổi này cũng có thể gây ra vấn đề tương thích, đặc biệt với các ứng dụng và SDK phụ thuộc vào native code, vì vậy nhà phát triển cần cập nhật phần mềm với kích thước trang 16KB trong đầu
• Google đang cung cấp cho nhà phát triển các công cụ để kiểm thử và chuẩn bị cho quá trình chuyển đổi này thông qua tùy chọn nhà phát triển 16KB và hỗ trợ emulator
• Trang 16KB hiện mới chỉ áp dụng cho thiết bị Android dựa trên ARM, nhưng trong tương lai có khả năng mở rộng sang các nền tảng phần cứng khác
• Ngoài việc điều chỉnh ứng dụng và SDK cho phù hợp với kích thước trang 16KB, nhà phát triển cũng cần cân nhắc tác động của kích thước trang lớn hơn lên mức sử dụng bộ nhớ và thực hiện tối ưu bộ nhớ nếu cần
• Việc chuyển sang trang 16KB là một nỗ lực quan trọng đòi hỏi sự phối hợp trên toàn bộ hệ sinh thái Android, nhưng cuối cùng sẽ mang lại hiệu năng và hiệu quả tốt hơn cho người dùng

[GN⁺]

Ý kiến trên Hacker News

• Gần đây Debian kernel đã bắt đầu công việc biên dịch ARM64 kernel với kích thước trang 16KiB

  • Cũng đang có thảo luận bổ sung kích thước trang 64KiB
  • DART IOMMU trên Apple M1 yêu cầu kích thước trang tối thiểu 16KiB nên dự kiến hiệu quả sẽ tăng

• Hệ thống Android hỗ trợ 16KB đầu tiên sẽ sớm được cung cấp trên một số thiết bị dưới dạng tùy chọn nhà phát triển

  • Có thể kiểm thử và sửa lỗi thông qua tùy chọn nhà phát triển
  • Binary ứng dụng độc lập với kích thước trang có thể chạy trên cả thiết bị 4KB và 16KB

• Tôi tò mò khi nào ứng dụng lại không độc lập với kích thước trang

  • Muốn biết vấn đề này xảy ra trong những tình huống nào

• Việc không hỗ trợ đồng thời tiến trình 4KB và 16KB mà dùng mặc định 16KB là một vấn đề

  • Binary cũ có thể bị hỏng và có lo ngại hiệu năng emulator suy giảm
  • Cần một kernel vẫn hỗ trợ cả trang 4KB
  • Có lẽ sẽ hợp lý hơn nếu trong thiết kế CPU, mục bảng trang 16KB có thể ánh xạ theo đơn vị 4KB

• iOS đã dùng trang 16KB từ sau khi chuyển sang 64-bit

  • ARM Mac cũng kế thừa thiết kế này

• Trước đây RHEL từng thử dùng trang 64KB trên AARCH64 nhưng cuối cùng phải quay lại vì quá nhiều lỗi

  • Nỗ lực của Google rất ấn tượng, nhưng chưa rõ có thành công hay không

• Tôi tự hỏi Asahi đã giúp được bao nhiêu cho công việc kernel và hệ sinh thái nhằm kích hoạt trang 16KB

  • Việc RISC-V bị cố định ở trang 4KB có vẻ là một sai lầm

• iOS đã dùng trang 16K từ rất lâu rồi

  • OSX đã chuyển sang trang 16K cùng với M1 vào năm 2020
  • Windows vẫn dừng ở trang 4K ngay cả trên AArch64
  • Linux hỗ trợ nhiều kích thước trang khác nhau. Asahi là 16K

• Tôi tò mò liệu việc tăng kích thước trang có ảnh hưởng tiêu cực đến hiệu năng I/O hoặc tuổi thọ flash hay không

  • Cũng muốn biết đơn vị ghi của các thiết bị flash được quản lý hiện đại có lớn hơn 4KB hay 16KB không

• Đã đo được cải thiện hiệu năng

  • Đặc biệt ứng dụng camera khởi động nhanh hơn
  • Tôi tò mò còn những khả năng tối ưu hóa nào khác
  • Cũng tự hỏi liệu có thể giảm thiểu mã khởi tạo bằng cách giống như kiểu "image dump" của Lisp hay không

• Mức tăng hiệu năng 5-10% có vẻ là con số lớn

  • Nếu page walk đắt đến vậy thì liệu không nên có TLB lớn hơn sao
  • Việc mức dùng bộ nhớ tăng 9% cũng là con số lớn
  • Tôi tò mò nó đã ảnh hưởng đến mức dùng bộ nhớ như thế nào

[gurugio]

• Các thiết bị lưu trữ mới nhất lưu IO vào bộ nhớ đệm bên trong thiết bị, nên dự kiến sẽ không có khác biệt đáng kể ngay cả khi IO xảy ra ở mức 16KB.
• Hiệu năng của các thiết bị như camera, GPU, nơi hiệu năng rất quan trọng và được cấp phát các trang liên tiếp, sẽ được cải thiện.
• Vì TLB là bộ nhớ đệm phần cứng nên có vẻ chi phí sẽ là vấn đề.
• Có vẻ họ đánh giá rằng việc mức sử dụng bộ nhớ tăng 10% không phải là vấn đề lớn so với dung lượng bộ nhớ của các mẫu máy mới nhất.
• Việc hỗ trợ đồng thời 4k/16k đòi hỏi phải sửa từ lõi CPU đến phần lõi kernel, nên tôi nghĩ gần như là bất khả thi. Vì kernel đã tận dụng tính năng trang lớn như hugepage trong thời gian dài, nên tôi cho rằng việc vận hành với 16k sẽ không có vấn đề gì lớn. Còn các vấn đề phát sinh ở các tính năng của Android hay trong ứng dụng ngoài kernel thì Google sẽ phải quản lý.
• Dù sao đi nữa, trong bối cảnh bộ nhớ trên các lõi 64-bit ngày càng lớn, việc tăng kích thước trang vốn đã được bàn luận từ lâu trong thị trường máy chủ. Tôi nghĩ giờ đây smartphone cũng buộc phải áp dụng điều đó.