เพิ่มขนาดเพจ 16KB ให้ Android

 (android-developers.googleblog.com)
10 คะแนน โดย GN⁺ 2024-08-24 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เพจคือหน่วยขั้นต่ำที่ระบบปฏิบัติการใช้จัดการหน่วยความจำ
  • CPU ส่วนใหญ่รองรับขนาดเพจ 4 KB และ Android OS กับแอปพลิเคชันต่าง ๆ ก็ถูกปรับแต่งให้เหมาะกับขนาดเพจ 4 KB
  • CPU ของ ARM รองรับขนาดเพจ 16 KB และเมื่อ Android ใช้ขนาดนี้ ประสิทธิภาพจะดีขึ้น 5-10% ขณะที่การใช้หน่วยความจำเพิ่มขึ้นราว 9%
  • เพื่อปรับปรุงประสิทธิภาพของระบบปฏิบัติการโดยรวม และเปิดให้ผู้ผลิตอุปกรณ์เลือก trade-off นี้ได้ Android 15 จึงสามารถทำงานด้วยขนาดเพจ 4 KB หรือ 16 KB ได้
  • ระบบ Android ชุดแรกที่รองรับขนาดเพจ 16 KB จะเปิดให้ใช้งานผ่านตัวเลือกนักพัฒนาบนอุปกรณ์บางรุ่น

รายละเอียดทางเทคนิคของขนาดเพจ 16KB

  • CPU ส่วนใหญ่มีฮาร์ดแวร์เฉพาะที่เรียกว่า memory management unit (MMU) สำหรับแปลงที่อยู่ที่โปรแกรมกำลังใช้งานให้เป็นตำแหน่งจริงในหน่วยความจำ
  • การแปลงนี้ทำเป็นหน่วยตามขนาดเพจ
    • ทุกครั้งที่โปรแกรมต้องการหน่วยความจำเพิ่ม ระบบปฏิบัติการต้องเข้ามาเติมรายการใน "page table" และจัดสรรชิ้นส่วนหน่วยความจำนั้นให้กับโปรเซส
  • เมื่อขนาดเพจใหญ่ขึ้น 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 ขนาดไฟล์ปฏิบัติการ ELF จะเพิ่มขึ้นเพราะ padding ที่เพิ่มมาเพื่อให้จัดแนว 16KB แต่มีการปรับแต่งหลายอย่างเพื่อลดต้นทุนนี้
  • ระบบไฟล์แบบ sparse และอ่านอย่างเดียวทำให้หน้า 0 ที่ถูกสร้างขึ้นเพื่อรองรับ padding เพิ่มเติมสำหรับการจัดแนว 16KB ไม่ถูกเขียนลงดิสก์
  • ระบบไฟล์ที่อ่าน/เขียนได้จะจัดการหน้า 0 เป็นกรณี ๆ ไป

การจัดการหน่วยความจำ

  • มีการปรับ Linux page cache เพื่อไม่ให้ pre-read พื้นที่ padding ส่วนเกินเหล่านี้ ช่วยประหยัดการโหลดหน่วยความจำที่ไม่จำเป็น
  • เพจเหล่านี้เป็น padding ว่าง และโปรแกรมจะไม่อ่านมันเลย เป็นเพียงพื้นที่ที่อยู่ระหว่างส่วนที่ใช้งานได้ของโปรแกรมเพื่อจุดประสงค์ด้านการจัดแนวเท่านั้น

Linux kernel

  • Linux kernel ผูกกับขนาดเพจที่เลือกไว้อย่างลึกซึ้ง ดังนั้นตอน build kernel จึงต้องเลือกขนาดเพจที่จะใช้ ส่วนที่เหลือของระบบปฏิบัติการยังคงเหมือนเดิม

แอปพลิเคชัน Android

  • แอปพลิเคชันใดก็ตามที่มี native code หรือมี dependency ที่เกี่ยวข้อง จะต้องคอมไพล์ใหม่เพื่อให้เข้ากันได้กับอุปกรณ์ที่ใช้ขนาดเพจ 16KB
  • เนื่องจาก native code ในแอป Android และ SDK ส่วนใหญ่ถูก build โดยคำนึงถึงขนาดเพจ 4KB จึงต้องจัดแนวใหม่เป็น 16KB เพื่อให้ไบนารีใช้งานได้ทั้งบนอุปกรณ์ 4KB และ 16KB
  • สำหรับแอปและ SDK ส่วนใหญ่ กระบวนการนี้มี 2 ขั้นตอน:
    1. build native code ใหม่โดยจัดแนวเป็น 16KB
    2. หากมีการสมมติค่าขนาดเพจแบบฮาร์ดโค้ด ให้ทดสอบบนอุปกรณ์/อีมูเลเตอร์ 16KB และแก้ไข

การพัฒนาอุปกรณ์ 16 KB

  • อุปกรณ์ Android ที่วางจำหน่ายอยู่ในปัจจุบันยังไม่รองรับขนาดเพจ 16 KB
    • เพื่อแก้ปัญหานี้ Google กำลังทำงานร่วมกับพาร์ตเนอร์เพื่อเปิดให้ใช้งานตัวเลือกนักพัฒนาบนอุปกรณ์ที่มีอยู่แล้ว
  • จะมีการเปิดรองรับขนาดเพจ 16 KB ผ่านตัวเลือกนักพัฒนา
  • สามารถใช้ target อีมูเลเตอร์ 16 KB ใน Android Studio ได้

ตัวเลือกนักพัฒนา 16 KB

  • ใน Android 15 มีการเพิ่มตัวเลือกนักพัฒนาที่สลับระหว่างขนาดเพจ 16 KB และ 4 KB ได้
  • ใช้งานได้บน Pixel 8 และ Pixel 8 Pro และมีแผนรองรับอุปกรณ์เพิ่มเติม
  • หากต้องการใช้ตัวเลือกนักพัฒนา ต้องรีเซ็ตอุปกรณ์และปลดล็อก bootloader

16 KB บนเดสก์ท็อป x86_64

  • สามารถจำลองขนาดเพจ 16 KB ได้บน อีมูเลเตอร์ x86_64
  • ดาวน์โหลดและรันอีมูเลเตอร์เพจ 16 KB ได้จาก Android Studio SDK Manager

อนาคต

  • Android 15 และ AOSP รองรับเพจ 16 KB แล้ว และสามารถเปิดใช้งานได้ผ่านตัวเลือกนักพัฒนา
  • คาดหวังว่านักพัฒนาแอปและ SDK จะใช้ตัวเลือกนี้เพื่อเตรียมความพร้อมสำหรับอุปกรณ์ Android ที่มีประสิทธิภาพและความคุ้มค่าสูงขึ้น

ความเห็นของ GN⁺

  • การเปลี่ยนไปใช้ขนาดเพจ 16KB เป็นการเปลี่ยนแปลงสำคัญเพื่อยกระดับประสิทธิภาพและความคุ้มค่าของอุปกรณ์ Android
  • การใช้ขนาดเพจที่ใหญ่ขึ้นช่วยลด overhead ของการจัดการหน่วยความจำ และอาจช่วยให้ประสิทธิภาพโดยรวมของระบบดีขึ้น
  • อย่างไรก็ตาม การเปลี่ยนแปลงนี้อาจก่อให้เกิดปัญหาความเข้ากันได้ โดยเฉพาะกับแอปและ SDK ที่พึ่งพา native code ดังนั้นนักพัฒนาจึงควรอัปเดตซอฟต์แวร์โดยคำนึงถึงขนาดเพจ 16KB
  • Google กำลังมอบเครื่องมือให้นักพัฒนาทดสอบและเตรียมพร้อมสำหรับการเปลี่ยนผ่านนี้ ผ่านตัวเลือกนักพัฒนา 16KB และการรองรับอีมูเลเตอร์
  • ปัจจุบันเพจ 16KB ใช้กับอุปกรณ์ Android ที่ใช้ ARM เท่านั้น แต่ในอนาคตมีโอกาสขยายไปยังแพลตฟอร์มฮาร์ดแวร์อื่นได้
  • นอกเหนือจากการปรับแอปและ SDK ให้เข้ากับขนาดเพจ 16KB แล้ว นักพัฒนายังควรคำนึงถึงผลกระทบของขนาดเพจที่ใหญ่ขึ้นต่อการใช้หน่วยความจำ และทำ memory optimization หากจำเป็น
  • การเปลี่ยนผ่านสู่เพจ 16KB เป็นความพยายามสำคัญที่ต้องอาศัยความร่วมมือจากทั้งระบบนิเวศ Android แต่ท้ายที่สุดจะมอบประสิทธิภาพและความคุ้มค่าที่ดีกว่าให้ผู้ใช้

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2024-08-24
ความเห็นจาก Hacker News

  • เมื่อไม่นานมานี้ Debian kernel ได้เริ่มงานคอมไพล์ ARM64 kernel ด้วยขนาดเพจ 16KiB

    • กำลังมีการหารือเพิ่มเติมเรื่องการรองรับขนาดเพจ 64KiB ด้วย
    • DART IOMMU ของ Apple M1 ต้องการขนาดเพจขั้นต่ำ 16KiB จึงคาดว่าจะช่วยเพิ่มประสิทธิภาพ

  • ระบบ Android ตัวแรกที่รองรับ 16KB จะเปิดให้ใช้บนอุปกรณ์บางรุ่นผ่านตัวเลือกสำหรับนักพัฒนา

    • สามารถทดสอบและแก้ไขได้ผ่านตัวเลือกสำหรับนักพัฒนา
    • แอปพลิเคชันไบนารีที่ไม่ขึ้นกับขนาดเพจสามารถรันได้ทั้งบนอุปกรณ์ 4KB และ 16KB

  • สงสัยว่าเมื่อใดที่แอปพลิเคชันจะไม่เป็นอิสระจากขนาดเพจ

    • อยากรู้ว่าในสถานการณ์ใดปัญหานี้จะเกิดขึ้น

  • การใช้ค่าเริ่มต้นเป็น 16KB โดยไม่รองรับโปรเซส 4KB และ 16KB พร้อมกันเป็นปัญหา

    • ไบนารีเก่าอาจพังและมีความกังวลเรื่องประสิทธิภาพของอีมูเลเตอร์ที่ลดลง
    • จำเป็นต้องมีเคอร์เนลที่ยังรองรับเพจ 4KB ด้วย
    • การออกแบบ CPU ให้สามารถแมป page table entry ขนาด 16KB เป็นหน่วยย่อย 4KB ได้ก็น่าจะสมเหตุสมผล

  • iOS ใช้เพจ 16KB มาตั้งแต่เปลี่ยนผ่านไปสู่ 64 บิต

    • ARM Mac ก็สืบทอดแนวทางการออกแบบนี้มา

  • RHEL เคยลองใช้เพจ 64KB บน AARCH64 ในอดีต แต่สุดท้ายต้องย้อนกลับเพราะบั๊กจำนวนมาก

    • ความพยายามของ Google น่าประทับใจ แต่ยังไม่แน่ใจว่าจะสำเร็จหรือไม่

  • สงสัยว่า Asahi ได้ช่วยงานฝั่งเคอร์เนลและอีโคซิสเต็มสำหรับการเปิดใช้เพจ 16KB มากแค่ไหน

    • การที่ RISC-V ถูกตรึงไว้ที่เพจ 4KB ดูเหมือนเป็นความผิดพลาด

  • iOS ใช้เพจ 16K มานานแล้ว

    • OSX เปลี่ยนมาใช้เพจ 16K พร้อมกับ M1 ในปี 2020
    • Windows ยังคงอยู่ที่เพจ 4K แม้บน AArch64
    • Linux รองรับขนาดเพจได้หลากหลาย โดย Asahi ใช้ 16K

  • สงสัยว่าการเพิ่มขนาดเพจจะส่งผลลบต่อประสิทธิภาพ I/O หรืออายุการใช้งานแฟลชหรือไม่

    • และก็สงสัยด้วยว่าอุปกรณ์แฟลชแบบมีการจัดการสมัยใหม่มีหน่วยการเขียนที่ใหญ่กว่า 4KB หรือ 16KB หรือไม่

  • มีการวัดพบว่าประสิทธิภาพดีขึ้น

    • โดยเฉพาะแอปกล้องเปิดได้เร็วขึ้น
    • สงสัยว่ายังมีโอกาสปรับแต่งด้านอื่นอีกหรือไม่
    • สงสัยว่าจะลดโค้ดเริ่มต้นระบบให้เหลือน้อยที่สุดได้หรือไม่ ด้วยแนวทางแบบเดียวกับ "image dump" ของ Lisp

  • การเพิ่มประสิทธิภาพ 5-10% ดูเป็นตัวเลขที่มาก

    • ถ้า page walk มีต้นทุนสูงขนาดนั้น ก็น่าสงสัยว่าไม่ควรมี TLB ที่ใหญ่กว่านี้หรือ
    • การใช้หน่วยความจำเพิ่มขึ้น 9% ก็ดูเป็นตัวเลขที่มากเช่นกัน
    • สงสัยว่ามันส่งผลต่อการใช้หน่วยความจำอย่างไร
 
gurugio 2024-08-30
  • เนื่องจากสตอเรจรุ่นใหม่จะเก็บ IO ไว้ในแคชภายในสตอเรจอยู่แล้ว จึงคาดว่าแม้จะเกิด IO ที่ 16KB ก็ไม่น่าจะมีความแตกต่างมากนัก
  • ประสิทธิภาพของอุปกรณ์อย่างกล้องหรือ GPU ที่ต้องการประสิทธิภาพสูงและได้รับการจัดสรรเพจที่ต่อเนื่องกันจะดีขึ้น
  • TLB เป็นฮาร์ดแวร์แคช จึงดูเหมือนว่าต้นทุนจะเป็นประเด็น
  • ดูเหมือนว่าจะตัดสินว่า การเพิ่มการใช้หน่วยความจำ 10% ไม่ใช่ปัญหาใหญ่อะไรเมื่อเทียบกับขนาดหน่วยความจำของอุปกรณ์รุ่นใหม่
  • การรองรับทั้ง 4k/16k พร้อมกันนั้นต้องแก้ตั้งแต่ส่วนของ CPU core ไปจนถึง kernel core ดังนั้นผมคิดว่าแทบเป็นไปไม่ได้เลย แต่เนื่องจากเคอร์เนลใช้ความสามารถของเพจขนาดใหญ่ เช่น hugepage มานานแล้ว จึงคิดว่าการทำงานแบบ 16k ไม่น่ามีปัญหาใหญ่ องค์ประกอบอื่นนอกเหนือจากเคอร์เนล เช่น ฟังก์ชันของ Android หรือแอปต่าง ๆ หากมีปัญหา ก็คงเป็นสิ่งที่ Google ต้องจัดการ
  • อย่างไรก็ตาม ในสถานการณ์ที่หน่วยความจำของคอร์ 64 บิตเพิ่มขึ้นเรื่อย ๆ การเพิ่มขนาดเพจนั้นเป็นสิ่งที่มีการพูดคุยกันในตลาดเซิร์ฟเวอร์มาตั้งนานแล้ว ผมคิดว่าสมาร์ตโฟนก็คงต้องนำมาใช้โดยหลีกเลี่ยงไม่ได้เช่นกัน.