เป้าหมายสุดท้ายของการป้องกันล่วงหน้าแบบเรียลไทม์

 (lwn.net)
2 คะแนน โดย GN⁺ 2023-11-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

จุดหมายปลายทางของการรองรับ preemption แบบเรียลไทม์บน Linux

  • งานเพิ่มการรองรับแบบเรียลไทม์ให้กับ Linux เริ่มต้นมาตั้งแต่ปี 2004 และตอนนี้ได้เข้าสู่ช่วงเกือบเสร็จสมบูรณ์แล้ว
  • เป้าหมายของ preemption แบบเรียลไทม์คือทำให้โปรเซสที่มีลำดับความสำคัญสูงสุดสามารถทำงานได้ด้วยความหน่วงต่ำที่สุดเท่าที่จะเป็นไปได้ และเพื่อสิ่งนี้ เคอร์เนลจึงถูกทำให้สามารถถูก preempt ได้ในสถานการณ์ให้ได้มากที่สุด
  • งานนี้ส่งผลให้เกิดการเขียนส่วนแกนหลักของเคอร์เนลขึ้นใหม่ และมอบประโยชน์ที่ไปไกลกว่ากรณีใช้งานแบบเรียลไทม์

การแก้ปัญหา printk()

  • ฟังก์ชัน printk() ที่ใช้ส่งข้อความไปยัง system console และ log ในเคอร์เนลทำงานแบบ synchronous จึงจะไม่คืนค่ากลับจนกว่าข้อความจะถูกส่งไปยังปลายทางที่ตั้งค่าไว้ทั้งหมด
  • นักพัฒนาเรียลไทม์ได้ย้ายเอาต์พุตของ printk() ไปไว้ในเธรดแยกเพื่อทำให้เป็นแบบ asynchronous แต่สิ่งนี้เป็นเพียงแนวทางแก้ชั่วคราว
  • ปัญหา printk() ซึ่งเริ่มมีการทำงานอย่างจริงจังตั้งแต่ปี 2018 กำลังถูกแก้ไขผ่านแพตช์ราว 300 ชุด และยังคงเหลือปัญหาซับซ้อนอีกเล็กน้อยที่ต้องจัดการ

แนวโน้มการรวมโค้ด preemption แบบเรียลไทม์เข้าสู่ mainline

  • มีการแสดงความหวังว่าส่วนที่เหลือของโค้ด preemption แบบเรียลไทม์จะถูกรวมเข้าสู่ mainline ก่อนครบรอบ 20 ปีในช่วงปลายปี 2024
  • แม้จะยังไม่มีความเปลี่ยนแปลงล่าสุดในโค้ด printk() แต่โค้ด handover ได้ถูกปรับเพื่อให้สามารถอัปเดต console driver ได้ทีละตัว
  • โค้ดถูกเปลี่ยนให้ข้อความสำคัญถูกคัดลอกเข้าสู่ message buffer อย่างสมบูรณ์ก่อนที่บรรทัดแรกจะถูกพิมพ์ออกมา และเพื่อป้องกันระบบล่มจาก console driver ที่มีปัญหา จึงมีการบันทึกข้อความลงใน safe console ก่อน

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

  • งานเพิ่มการรองรับ preemption แบบเรียลไทม์ให้กับ Linux kernel ใกล้เสร็จสมบูรณ์แล้ว และจะมอบประโยชน์อย่างมากแก่ระบบที่ต้องการงานแบบเรียลไทม์
  • การทำให้ฟังก์ชัน printk() เป็น asynchronous มีบทบาทสำคัญต่อการเพิ่มการตอบสนองของระบบและการบรรลุเป้าหมายของ preemption แบบเรียลไทม์
  • บทความนี้แสดงให้เห็นถึงความก้าวหน้าสำคัญของการพัฒนา Linux kernel และนำเสนอเนื้อหาที่น่าสนใจสำหรับผู้ที่สนใจการพัฒนาเคอร์เนล

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

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

 
GN⁺ 2023-11-17
ความเห็นจาก Hacker News

  • ข้อดีของไมโครเคอร์เนล QNX

    • ไมโครเคอร์เนล QNX รับประกันความน่าเชื่อถือด้วยการกำหนดเพดานให้ทุกงานมานานหลายทศวรรษ
    • โค้ดของไมโครเคอร์เนลมีเพียงไม่กี่หมื่นบรรทัด และรับผิดชอบแค่การจัดสรรหน่วยความจำ การจัดคิว CPU และการส่งข้อความระหว่างโปรเซส
    • ฟังก์ชันอื่นทั้งหมดรวมถึงไดรเวอร์และตัวบันทึกล็อกอยู่ใน user space จึงสามารถถูก preempt ได้โดยเธรดที่มีลำดับความสำคัญสูงกว่า
    • เคอร์เนล QNX ไม่ทำงานกับสตริงเลย จึงไม่มีปัญหาที่เกิดจากการพาร์สสตริง การฟอร์แมต หรือการส่งข้อความ

  • ปัญหาของการประมวลผลแบบเรียลไทม์ใน Linux

    • Linux มีโครงสร้างที่ไม่เหมาะกับการประมวลผลแบบเรียลไทม์ โดยโค้ดเคอร์เนลมีขนาดหลายล้านบรรทัด และต้องทำให้โค้ดทั้งหมดสามารถถูก preempt ได้
    • ความไม่เหมาะสมในฐานะสถาปัตยกรรมเรียลไทม์ทำให้ต้องใช้เวลาหลายทศวรรษในการแก้ไข
    • การโฟกัสเฉพาะปัญหาระดับเคอร์เนลอาจทำให้มองข้ามปัญหาระดับ CPU

  • ฟังก์ชันการล็อกของเคอร์เนลและกรณีใช้งานจริง

    • อธิบายว่าตัวอย่างที่เคอร์เนลพยายามอย่างมากเพื่อพิมพ์ข้อความล็อกแม้ในสถานการณ์ที่ระบบล่ม ถูกนำไปใช้ในงานดีพลอยจริงอย่างไร

  • ความเป็นไปได้ในการแทนที่ชุดฮาร์ดแวร์/ซอฟต์แวร์เรียลไทม์

    • ตั้งคำถามว่าชุดฮาร์ดแวร์/ซอฟต์แวร์ที่ต้องการการประมวลผลแบบเรียลไทม์ จะสามารถถูกแทนที่ด้วยชิป ARM และ x86 ที่ราคาถูกกว่า กินไฟต่ำ และมีความถี่สัญญาณนาฬิกาสูงได้หรือไม่
    • กล่าวถึงว่าความสำคัญของการประมวลผลแบบเรียลไทม์ที่สมบูรณ์แบบอาจลดลงเมื่อความเร็วสัญญาณนาฬิกาสูงขึ้น

  • การแยกความต่างระหว่างแอปพลิเคชันเรียลไทม์แบบ "hard" กับ "soft"

    • สำหรับแอปพลิเคชันเรียลไทม์แบบ "hard" ควรหลีกเลี่ยงการใช้ OS แบบใช้งานทั่วไปอย่าง Linux
    • สำหรับแอปพลิเคชันเรียลไทม์แบบ "soft" (เช่น วิดีโอคอนเฟอเรนซ์ การเล่นเสียง) ความหน่วงเล็กน้อยหรือการหลุดของเฟรมเล็กน้อยไม่ใช่ปัญหาใหญ่
    • การถกเถียงเรื่องการทำให้ Linux กลายเป็น real-time OS มุ่งเน้นไปที่กรณีใช้งานแบบ "soft" real-time ที่ทำได้อยู่แล้ว
    • การทำให้เคอร์เนลสามารถถูก preempt ได้ทั้งหมดและเพิ่มการควบคุมด้าน scheduling มีความหมายต่อการดูแลจัดการระบบที่ดีมากกว่าการตั้งใจจะมาแทน real-time OS หรือโค้ดแบบ bare metal

  • การประมวลผลแบบเรียลไทม์ของเคอร์เนล Linux และข้อจำกัดของฮาร์ดแวร์

    • แม้เคอร์เนล Linux จะรองรับการประมวลผลแบบเรียลไทม์ แต่ฮาร์ดแวร์อาจไม่รองรับเรียลไทม์เพราะแคชและฟังก์ชันภายใน CPU ที่ซับซ้อน
    • สำหรับการประมวลผลแบบเรียลไทม์อย่างแท้จริง มักนิยมสถาปัตยกรรม CPU ที่เรียบง่ายมากกว่าฮาร์ดแวร์ที่ซับซ้อน

  • ปัญหาของ synchronous logging

    • เคยเจอปัญหาที่ synchronous logging อย่าง GLOG (ไลบรารีล็อกของ Google) ถูกบล็อกด้วย disk I/O จนทำให้บริการหน่วง

  • วิธีรับประกันการตอบสนองของโปรเซสเฉพาะ

    • หากให้ความสำคัญกับการตอบสนองของโปรเซสใดเป็นพิเศษ ควรจัดสรรคอร์ CPU เฉพาะและพื้นที่หน่วยความจำแบบต่อเนื่องให้โปรเซสนั้น พร้อมเปิดให้เข้าถึงการ์ดเครือข่ายได้โดยตรงโดยแยกจากส่วนอื่นของ OS

  • ความสามารถ real-time preemption ของ Linux และประสบการณ์ในอดีต

    • แชร์ประสบการณ์ในอดีตที่เคยใช้แพตช์ RT_PREEMPT กับเคอร์เนล Linux สำหรับอุปกรณ์วิทยาศาสตร์ และประทับใจกับค่าความหน่วงและ jitter ที่ดีขึ้น

  • ผลกระทบต่อผู้ใช้ทั่วไป

    • ตั้งคำถามว่าความสามารถด้านการประมวลผลแบบเรียลไทม์มีความหมายอย่างไรต่อผู้ใช้ทั่วไป จะเปิดใช้เฉพาะในบางสถานการณ์หรือไม่ และจะช่วยเพิ่มความลื่นไหลในการตอบสนองของระบบทั่วไปได้ด้วยหรือไม่