ในขณะที่หน้าต่างการรวม Linux 6.4 กำลังจะปิดในสุดสัปดาห์นี้ วันนี้ในวันสุดท้ายของช่วงเวลา Jens Axboe ส่งไพพ์การสนับสนุน FMODE_NOWAIT ซึ่งเป็นสิ่งที่เขาอธิบายว่าเป็นการปรับปรุงประสิทธิภาพและประสิทธิภาพครั้งใหญ่
ด้วยรูปแบบก่อนหน้าของ FMODE_NOWAIT ที่รองรับไปป์ แพตช์ Axboe อธิบายว่า:
“สิ่งหนึ่งที่ช้ากว่าที่ฉันต้องการเสมอสำหรับ io_uring คือการจัดการกับไพพ์ พวกเขาไม่รองรับ IOCB_NOWAIT ดังนั้นเราจำเป็นต้องถ่อไปที่ io-wq สำหรับการจัดการ ซีรีส์นี้เพิ่มการรองรับ FMODE_NOWAIT ให้กับไพพ์”
แต่สิ่งที่น่าสนใจจริงๆ คือขนาดของประสิทธิภาพ/ประสิทธิภาพที่ได้รับจากมัน:
“อยากรู้ว่าเป็นอย่างไร ฉันเขียนเกณฑ์มาตรฐานเล็ก ๆ ที่เปิด 128 ไปป์ จากนั้นทำการอ่านและเขียน 256 รอบ สิ่งนี้ถูกรัน 10 ครั้ง ละทิ้งการรันครั้งแรกเพราะมันช้ากว่าเล็กน้อยเสมอ ก่อนแพตช์:
เฉลี่ย: 262.52 msec
Stdev: 2.12 msec
ต่ำสุด: 261.07 msec
สูงสุด 267.91 msecและหลังแพทช์:
เฉลี่ย: 24.14 msec
Stdev: 9.61 msec
ต่ำสุด: 17.84 msec
สูงสุด: 43.75 มิลลิวินาทีหรือปรับปรุงประสิทธิภาพ (และประสิทธิภาพ) ประมาณ 10 เท่า
ฉันรันแพตช์ผ่านท่อ ltp และการทดสอบการประกบ ไม่พบการถดถอย เมื่อดูที่การติดตาม io_uring เราจะเห็นว่าเราไม่มีการติดตาม io_uring_queue_async_work() อีกต่อไปหลังจากแพตช์ ซึ่งก่อนหน้านี้ทุกอย่างดำเนินการผ่าน io-wq”
ต่อมา เพิ่มในชุดแพทช์นั้น:
“ด้านบน การทดสอบใช้สำหรับไพพ์ที่ว่างเปล่าเมื่อมีการอ่าน หากการทดสอบถูกเปลี่ยนให้มีข้อมูลเมื่อใด ก็จะดูดียิ่งขึ้น:
ก่อน:
Avg: 249.24 msec
Stdev: 0.20 msec
ต่ำสุด: 248.96 msec
สูงสุด: 249.53 msecหลัง:
เฉลี่ย: 10.86 msec
Stdev: 0.91 msec
ต่ำสุด: 10.02 msec
สูงสุด: 12.67 มิลลิวินาทีหรือประมาณการปรับปรุง 23 เท่า”
แพตช์ที่ตั้งค่าไว้สำหรับการรวมเข้ากับ Linux 6.4 ตั้งค่าให้ FMODE_NOWAIT รองรับไพพ์ แต่ปิดใช้งานหากใช้ ประกบ/vmsplice บนท่อ คำขอดึงข้อมูลนี้คือสิ่งที่เกิดขึ้นแล้ว รอการสนับสนุนไปป์ FMODE_NOWAIT
