แก้โค้ด Linux แค่ 30 บรรทัด ก็ลดการใช้พลังงานได้สูงสุด 30%

 (spectrum.ieee.org)
12 คะแนน โดย GN⁺ 2025-04-22 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • การใช้ไฟฟ้าของศูนย์ข้อมูลในสหรัฐฯ คิดเป็นประมาณ 4% ของการใช้ไฟฟ้าทั้งประเทศ ณ ปี 2023 และคาดว่าจะเพิ่มเป็น 12% ภายในปี 2028
  • ทีมนักวิจัยจากมหาวิทยาลัยวอเตอร์ลูพัฒนาวิธีลดการใช้พลังงานของศูนย์ข้อมูลได้สูงสุด 30% ผ่าน การปรับปรุงวิธีประมวลผลเครือข่ายของเคอร์เนล Linux
  • หัวใจสำคัญคือ การควบคุม busy polling แบบไดนามิก โดย สลับระหว่างโหมด interrupt และ polling อัตโนมัติ ตามสภาพทราฟฟิก
  • การเปลี่ยนแปลงนี้ทำได้ด้วย การแก้โค้ดเพียงราว 30 บรรทัด และถูกรวมอย่างเป็นทางการในเคอร์เนล Linux 6.13
  • มี ศักยภาพในการนำไปใช้ได้อย่างกว้างขวาง กับศูนย์ข้อมูลและเว็บเซิร์ฟเวอร์ที่ใช้ Linux พร้อมตอกย้ำ แนวคิดการพัฒนาซอฟต์แวร์ที่ให้ความสำคัญกับประสิทธิภาพการใช้พลังงาน

ลดการใช้พลังงานของศูนย์ข้อมูลได้สูงสุด 30% ด้วยการแก้โค้ดเคอร์เนล Linux แค่ 30 บรรทัด

ความกังวลต่อการใช้พลังงานที่เพิ่มขึ้น

  • ทราฟฟิกเว็บส่วนใหญ่ทั่วโลกทำงานผ่าน ศูนย์ข้อมูล ซึ่งเป็นโครงสร้างพื้นฐานของ แอปพลิเคชันใช้พลังงานสูงอย่างบริการ AI
  • ในสหรัฐฯ ศูนย์ข้อมูลใช้ไฟฟ้าประมาณ 4% ในปี 2023 และคาดว่าจะเพิ่มเป็น 12% ภายในปี 2028

แก่นของปัญหา: วิธีประมวลผลเครือข่ายในเคอร์เนล Linux

  • เคอร์เนล Linux ใช้ทั้ง interrupt และ polling ในการประมวลผลแพ็กเก็ตเครือข่าย
    • interrupt: เมื่อมีแพ็กเก็ตใหม่เข้ามา CPU จะหยุดงานที่กำลังทำอยู่เพื่อไปประมวลผล
    • busy polling: เพื่อลด latency ระบบจะ คอยตรวจสอบเป็นระยะโดยไม่สนว่ามีแพ็กเก็ตหรือไม่ → ไม่มีประสิทธิภาพ

วิธีแก้: สลับ busy polling แบบไดนามิก

  • ทีมของศาสตราจารย์ Martin Karsten จากมหาวิทยาลัยวอเตอร์ลู เสนอให้ทำงานตามทราฟฟิกเครือข่าย
    • ทราฟฟิกสูง: ใช้ busy polling
    • ทราฟฟิกต่ำ: สลับไปใช้ interrupt
  • ผลลัพธ์คือช่วยลดการใช้พลังงานที่ไม่จำเป็นและเพิ่มความยืดหยุ่น

การแก้โค้ดและสถานะการนำไปใช้

  • พัฒนาร่วมกับวิศวกรของ Fastly Joe Damato โดยใช้วิธี จัดเรียงโค้ดในเคอร์เนลเดิมใหม่
  • ไม่ต้องเขียนโค้ดใหม่ แต่ ปรับโครงสร้างเดิมจนเกิดการแก้ไขราว 30 บรรทัด
  • ถูกรวมอย่างเป็นทางการใน เคอร์เนล Linux 6.13 (ออกในเดือนมกราคม 2025)
    → เคอร์เนลคอมมิต

ผลการประหยัดพลังงาน

  • ในแอปพลิเคชันที่เน้นงานเครือข่าย สามารถ ลดการใช้พลังงานได้สูงสุด 30%
    • แอปพลิเคชันทั่วไปอาจลดได้ไม่มากเท่านี้
  • เนื่องจาก ปรับตัวตามการเปลี่ยนแปลงของทราฟฟิกได้อัตโนมัติ จึงเหมาะกับศูนย์ข้อมูล
  • สามารถขยายไปใช้กับเว็บเซิร์ฟเวอร์บน Linux (เช่น nginx, Apache) ได้

การขยายผลในชุมชนและอิทธิพลต่อโอเพนซอร์ส

  • Damato มีแผนนำเทคนิคนี้ไปใช้กับ H2O server ของ Fastly
  • เนื่องจากเป็นโค้ดเคอร์เนลโอเพนซอร์ส นักพัฒนาเว็บเซิร์ฟเวอร์รายอื่นก็สามารถนำไปอ้างอิงได้
  • คาดว่าจะเป็นแรงกระตุ้นในการ ฟื้นคืนวัฒนธรรมการพัฒนาที่เน้นประสิทธิภาพพลังงาน

ความหมายเชิงแนวคิดของงานวิจัย

  • “ในยุค 90 การเพิ่มประสิทธิภาพการใช้ทรัพยากรคือพื้นฐานของวิทยาการคอมพิวเตอร์” แต่ในช่วง 20 ปีที่ผ่านมา อุตสาหกรรมให้ความสำคัญกับประสิทธิภาพจนมองข้ามเรื่องความคุ้มค่า
  • งานวิจัยนี้แสดงให้เห็นว่า “การปรับปรุงโค้ดเพียงเล็กน้อยอาจนำไปสู่การประหยัดพลังงานมหาศาลได้” และชี้ทิศทางของ การพัฒนาซอฟต์แวร์อย่างยั่งยืน

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

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

 
GN⁺ 2025-04-22
ความเห็นจาก Hacker News

  • Linux ได้เพิ่มฟีเจอร์ busy polling สำหรับเครือข่ายประสิทธิภาพสูง ซอฟต์แวร์ Linux ส่วนใหญ่ไม่ได้ใช้สิ่งนี้ แต่ซอฟต์แวร์ที่ใช้ในดาต้าเซ็นเตอร์จะไม่มีประสิทธิภาพด้านพลังงานเมื่อระบบไม่ได้ยุ่ง แพตช์นี้ทำให้สามารถปิดมันได้เมื่อระบบไม่ยุ่ง และช่วยกู้คืนประสิทธิภาพการใช้พลังงาน

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

  • งานจำนวนมากในดาต้าเซ็นเตอร์ประสิทธิภาพสูงจริง ๆ แล้วไม่ได้ผ่าน network stack ของเคอร์เนล Linux

    • แต่ใช้ DPDK, XDP หรือ user-space stack อย่าง Onload หรือ VMA แทน และบ่อยครั้ง SmartNICs จะทำ hardware offload ในกรณีเหล่านี้ แพตช์นี้ใช้ไม่ได้
    • อย่างไรก็ตาม แพตช์นี้จะช่วยได้อย่างชัดเจนในคอนฟิกที่เคอร์เนลอยู่ใน data path (CDNs, โหนด ingress, VM, ระบบ Linux แบบฝังตัว ฯลฯ) มันคงไม่ส่งผลมากกับงานที่หลบเลี่ยงเคอร์เนลไปแล้วเพราะปัญหาด้านประสิทธิภาพหรือ latency ตัวเลขประหยัดไฟ 30% ในพาดหัวนั้นขึ้นอยู่กับสถานการณ์อย่างมาก

  • ดูรายละเอียดเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงนี้ได้ที่ https://lwn.net/Articles/1008399/

  • เป็นการเปลี่ยนแปลงที่ยอดเยี่ยมจริง ๆ ในฐานะผู้เชี่ยวชาญด้าน high-performance computing ผมมักสงสัยอยู่บ่อย ๆ ว่าพลังงานถูกสูญเปล่าไปมากแค่ไหนเพราะโค้ดที่ไม่มีประสิทธิภาพ และมันจะกลายเป็นปัญหาใหญ่เพียงใดเมื่อการประมวลผลระดับดาวเคราะห์ขยายตัวต่อไป

    • โดยส่วนตัวแล้ว ผมรู้สึกว่ามีหน้าที่ทางศีลธรรมที่ต้องทำให้โค้ดมีประสิทธิภาพที่สุดเท่าที่จะเป็นไปได้ โดยเฉพาะเมื่อมีงานที่รันอยู่บน CPU หลายร้อยตัวเป็นเวลาหลายเดือน

  • ในทางกลับกัน Meta มีแฮ็กที่ทำให้ GPU ยุ่งอยู่ตลอดเพื่อให้การใช้พลังงานคงที่มากขึ้นระหว่างการฝึก LLM ตัวอย่างเช่น ไม่ต้องการให้พลังงานลดลงมากในช่วง batch synchronization

  • นี่หมายความว่า "adaptive interrupt moderation" ในเคอร์เนลไม่ได้ใช้อีกต่อไปแล้วหรือ? ผมไม่ได้ทำงานด้านนี้มาราว 15 ปีหรือมากกว่านั้นแล้ว แต่ตอนนั้นเคอร์เนลจะปรับตัวโดยใช้ interrupt เมื่อความเร็วเครือข่ายต่ำ และเมื่อเกินจุดหนึ่งก็จะปิด interrupt แล้วใช้ polling แทน

    • ปัญหาที่พยายามจะแก้คือการเปลี่ยนแปลงของทราฟฟิกที่ฉับพลันและรุนแรง เช่น มีการสร้างลูปในการสวิตช์และเกิด packet storm ตามมา ในกรณีนี้ interrupt จะเข้ามาเร็วเกินไปจนระบบมีเวลานอก interrupt ไม่พอที่จะปิด interrupt ได้ ดังนั้นทางแก้คือทำให้เราเตอร์ Linux มีคอร์มากกว่าจำนวนอินเทอร์เฟซเครือข่าย

  • ถ้ามีคำว่า "Up To" อยู่ในประโยค ก็แปลว่าตามตัวอักษรแล้วอะไรก็เป็นไปได้ทั้งหมด

  • นอกเรื่องนิดหน่อย แต่ดีใจที่ได้กลับมาอ่านงานเขียนเกี่ยวกับ Joe Damato อีกครั้ง ทำให้นึกถึงวันเก่า ๆ ตอนแรกผมอ่านบทความของ James Gollick เกี่ยวกับ tcmalloc แล้วได้รู้จัก packagecloud.io จากนั้นก็ได้เจอบทความสุดยอดของ Joe

  • ย่อหน้าสำคัญ:

    • "การประหยัดพลังงานนี้มีข้อควรระวังอยู่บ้าง 30% เป็นกรณีดีที่สุดที่ใช้กับ network stack หรือส่วนการสื่อสาร Karsten อธิบายว่า หากแอปพลิเคชันทำสิ่งนั้นเป็นหลัก คุณอาจเห็นการปรับปรุง 30% แต่ถ้าแอปพลิเคชันทำงานอย่างอื่นเยอะและใช้เครือข่ายเป็นครั้งคราว 30% ก็จะลดลงเป็นตัวเลขที่เล็กกว่านั้น"

  • โพสต์นี้ทำให้นึกถึงวันเก่า ๆ : https://didgets.substack.com/p/finding-and-fixing-a-billion-bug
 
semanticist 27 일 전

โอ้~ น่าสนใจดีนะครับ
ก็ทำให้นึกเหมือนกันว่ายังไม่มีซอฟต์แวร์ที่สมบูรณ์แบบจริง ๆ