หลังจากที่หน่วยความจำ folios ล้มเหลวในการสร้าง ใน Linux 5.15 การเปลี่ยนแปลงระดับต่ำนี้ในรหัสการจัดการหน่วยความจำเคอร์เนลที่อาจมีผลกระทบต่อประสิทธิภาพการทำงานกำลังมองหาพื้นที่สำหรับ Linux 5.16
ก่อนหน้าหน้าต่างผสาน Linux 5.16 ที่อาจเปิดขึ้นในวันพรุ่งนี้ Matthew Wilcox ส่งคำขอดึงเพื่อแนะนำ folios ให้กับเคอร์เนล นี่คือข้อความที่ตัดตอนมาจากคำขอดึงสำหรับผู้ที่ไม่คุ้นเคยกับโฟลิโอหรือลืมรายละเอียดในช่วงหลายเดือนที่ฟีเจอร์นี้ใช้งานได้:
จุดประสงค์ของการเปลี่ยนแปลงทั้งหมดนี้คือ อนุญาตให้ระบบไฟล์และแคชของเพจจัดการหน่วยความจำในส่วนที่ใหญ่กว่า PAGE_SIZE แผนเดิมคือการใช้หน้าแบบผสมเหมือนที่ THP ทำ แต่ฉันพบปัญหาเกี่ยวกับฟังก์ชันบางอย่างที่คาดหวังเพียงหน้าส่วนหัว ในขณะที่บางหน้าคาดว่าหน้าที่แม่นยำจะมีไบต์เฉพาะ ประเภทโฟลิโอช่วยให้ฟังก์ชันสามารถประกาศว่าต้องการเพียงส่วนหัวเท่านั้น เกือบจะบังเอิญ สิ่งนี้ทำให้เราสามารถลบการเรียกต่างๆ ไปยัง VM_BUG_ON(PageTail(page)) และ compound_head() ได้
คำขอดึงนี้แปลงเพียงบางส่วนของ MM หลักและแคชของเพจ สำหรับ 5.17 เราตั้งใจที่จะแปลงระบบไฟล์ต่างๆ (XFS และ AFS พร้อมแล้ว ระบบไฟล์อื่นอาจสร้างมันขึ้นมา) และยังแปลง MM และแคชเพจเป็นโฟลิโอเพิ่มเติม สำหรับ 5.18 โฟลิโอแบบหลายหน้าควรพร้อม
โฟลิโอแบบหลายหน้าช่วยปรับปรุงภาระงานบางอย่าง การชนะ 80% เป็นของจริง แต่ดูเหมือนจะเป็นเกณฑ์มาตรฐานที่ประดิษฐ์ขึ้น (การเริ่มต้น postgres ซึ่งไม่ใช่ภาระงานที่ร้ายแรง) ปริมาณงานจริง (เช่น การสร้างเคอร์เนล การรัน postgres ในสถานะคงที่ ฯลฯ) ดูเหมือนจะได้รับประโยชน์ระหว่าง 0-10% ฉันไม่เคยได้ยินเรื่องการสูญเสียประสิทธิภาพใด ๆ อันเป็นผลมาจากซีรีส์นี้ ไม่มีใครได้ทำการปรับแต่งประสิทธิภาพอย่างจริงจัง ฉันคิดว่าการปรับแต่งอัลกอริธึมการอ่านล่วงหน้าอาจทำให้ได้รับชัยชนะที่น่าสนใจกว่านี้ นอกจากนี้ยังมีที่อื่นๆ ที่เราสามารถเลือกสร้างโฟลิโอขนาดใหญ่แต่ในปัจจุบันไม่สามารถทำได้ เช่น การเขียนที่มีขนาดใหญ่กว่า PAGE_SIZE
สำหรับผู้ใช้ปลายทาง อาจหมายถึงประโยชน์ด้านประสิทธิภาพและมากกว่า เคอร์เนลที่ประสบความสำเร็จจะเผยแพร่ฟังก์ชันการทำงานรอบ ๆ โฟลิโอหน่วยความจำจะถูกสร้างขึ้น
ดูคำขอดึงสำหรับรายละเอียดเพิ่มเติม ตอนนี้เพื่อดูว่า Linus Torvalds ตัดสินใจที่จะดึงการเปลี่ยนแปลง ~2k+ บรรทัดนี้หรือหากมีการคัดค้านใหม่/ต่ออายุอื่นนอกเหนือจากการเพิ่ม
