การกลับมาของเฟรมพอยน์เตอร์

เว็บไซต์ของ Brendan: เริ่มต้นใช้งาน

• หน้าแรกของบล็อก Brendan Gregg ครอบคลุมหัวข้อหลากหลายเกี่ยวกับประสิทธิภาพระบบ, เครื่องมือ BPF, ประสิทธิภาพของ Linux และอื่น ๆ
• โพสต์ล่าสุดมีเนื้อหาอย่างการกลับมาของเฟรมพอยน์เตอร์, สารคดี eBPF, และเหตุใดเครื่องมือสังเกตการณ์ eBPF จึงไม่ใช่เครื่องมือความปลอดภัย
• บล็อกนี้ยังแบ่งปันทั้งเนื้อหาทางเทคนิคและงานประชุมกับการบรรยายต่าง ๆ ที่ Brendan มีส่วนร่วม

การกลับมาของเฟรมพอยน์เตอร์

• ในระบบที่ไม่มีเฟรมพอยน์เตอร์ การติดตามสแตกจะหยุดที่เลเยอร์ libc ทำให้เฟรมของแอปพลิเคชันหายไป
• Fedora และ Ubuntu แก้ปัญหานี้ด้วยการออกเวอร์ชันที่คอมไพล์ libc โดยใส่เฟรมพอยน์เตอร์ไว้เป็นค่าเริ่มต้น
• เฟรมพอยน์เตอร์ถูกใช้โดยโปรไฟเลอร์และดีบักเกอร์ภายนอก และแสดงผลเป็นภาพด้วย flame graph

เฟรมพอยน์เตอร์คืออะไร?

• ตามเอกสาร x86-64 ABI รีจิสเตอร์ CPU %rbp สามารถใช้เป็น "base pointer" ของสแตกเฟรมได้
• เทคนิคนี้ถูกใช้อย่างแพร่หลายสำหรับการติดตามสแตก และถูกใช้งานโดย Linux perf และ eBPF เป็นต้น

ปี 2004: การถอดเฟรมพอยน์เตอร์ออก

• ในปี 2004 Roger Sayle นักพัฒนา gcc ได้ผลักดันการเปลี่ยนแปลงให้หยุดสร้างเฟรมพอยน์เตอร์
• แม้การเปลี่ยนแปลงนี้จะช่วยเพิ่มประสิทธิภาพ แต่เมื่อ eBPF ถือกำเนิดขึ้น ทุกวันนี้ดีบักเกอร์/โปรไฟเลอร์บางตัวจึงประสบปัญหาจากเรื่องนี้

ปี 2005-2023: ฤดูหนาวของโปรไฟเลอร์ที่พัง

• การเปลี่ยนแปลงการถอดเฟรมพอยน์เตอร์ถูกนำไปใช้กับ x86-64 ด้วย แต่สถาปัตยกรรมนี้มีรีจิสเตอร์มากกว่า จึงแทบไม่ได้ประโยชน์มากนัก
• ผลคือดีบักเกอร์/โปรไฟเลอร์จำนวนมากทำงานได้ไม่สมบูรณ์

ปี 2014: Java in Flames

• เมื่อเข้าร่วม Netflix พบว่าการขาดการรองรับเฟรมพอยน์เตอร์ของ Java ทำให้สแตกของแอปพลิเคชันทั้งหมดเสียหาย
• เพื่อแก้ปัญหานี้ จึงได้พัฒนาแพตช์สำหรับคอมไพเลอร์ JVM c2

ปี 2015-2020: โอเวอร์เฮด

• โอเวอร์เฮดด้านประสิทธิภาพจากการเพิ่มเฟรมพอยน์เตอร์ให้กับทุกอย่าง โดยทั่วไปต่ำกว่า 1%
• ในไมโครบेंช์มาร์กบางกรณี โอเวอร์เฮดอาจสูงถึง 10%

ปี 2022: ความพยายามอัปสตรีม

• มีนัยว่าองค์กรใหญ่ เช่น Google, Meta, Netflix ได้เปิดใช้เฟรมพอยน์เตอร์กับทุกอย่างอยู่แล้ว
• แต่การทำให้การเปลี่ยนแปลงนี้เป็นค่าเริ่มต้นเพื่อให้ทุกคนได้ประโยชน์ ยังมีอุปสรรคหลายอย่าง

ปี 2023, 2024: เฟรมพอยน์เตอร์ใน Fedora และ Ubuntu

• Fedora ยอมรับข้อเสนอให้นำเฟรมพอยน์เตอร์กลับมาเปิดใช้อีกครั้ง
• Ubuntu ก็เปิดใช้เฟรมพอยน์เตอร์เป็นค่าเริ่มต้นในเวอร์ชัน 24.04 LTS เช่นกัน

หลังปี 2034: ไปไกลกว่าเฟรมพอยน์เตอร์

• มีหลายวิธีในการติดตามสแตก เช่น LBR, BTS, AET, DWARF, eBPF stack walking, ORC, SFrames และ shadow stack
• ในอนาคต SFrames หรือ shadow stack อาจถูกใช้สำหรับการติดตามสแตกทั้งหมด

บทสรุป

• การกลับมาของเฟรมพอยน์เตอร์ทำให้ CPU flame graph มีความหมายมากขึ้น ทำให้ Off-CPU flame graph ใช้งานได้จริงเป็นครั้งแรก และเปิดความเป็นไปได้ใหม่ ๆ
• นี่ยังเป็นชัยชนะของ continuous profiler ด้วย เพราะไม่จำเป็นต้องโน้มน้าวให้ลูกค้าเปลี่ยน OS เพื่อให้โปรไฟเลอร์ทำงานได้ครบถ้วนอีกต่อไป

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

• การกลับมาของเฟรมพอยน์เตอร์น่าจะช่วยการวิเคราะห์ประสิทธิภาพระบบและการดีบักได้อย่างมาก โดยเฉพาะในซอฟต์แวร์ระบบที่ซับซ้อนซึ่งต้องใช้เครื่องมือสำคัญในการวินิจฉัยปัญหาและปรับแต่งประสิทธิภาพ
• การเปลี่ยนแปลงนี้แสดงให้เห็นถึงความสำคัญของความร่วมมือและการมีส่วนร่วมของชุมชนโอเพนซอร์ส การตัดสินใจของ Fedora และ Ubuntu อาจส่งผลต่อดิสทริบิวชันอื่น ๆ และนำไปสู่การเปลี่ยนแปลงเชิงบวกต่อระบบนิเวศ Linux ทั้งหมด
• การนำเฟรมพอยน์เตอร์กลับมาใช้อีกครั้งเป็นเรื่องของการหาสมดุลระหว่างประสิทธิภาพที่ลดลงกับความง่ายในการดีบัก ซึ่งจะเข้าใจได้ดีขึ้นผ่านการทดสอบและการวิเคราะห์ประสิทธิภาพในสภาพแวดล้อมการใช้งานจริง
• สำหรับผู้ใช้ที่มีพื้นฐานทางเทคนิค การเปลี่ยนแปลงนี้อาจเป็นเรื่องน่าสนใจ และให้ข้อมูลที่เป็นประโยชน์แก่ทั้งนักพัฒนาและผู้ดูแลระบบที่สนใจการเพิ่มประสิทธิภาพของระบบ
• หากมีเทคโนโลยีหรือเครื่องมืออื่นที่ให้ความสามารถคล้ายเฟรมพอยน์เตอร์ ก็อาจใช้โปรไฟเลอร์แบบฮาร์ดแวร์ เช่น Intel VTune Profiler หรือ AMD uProf ซึ่งช่วยวิเคราะห์ประสิทธิภาพได้แม้ไม่มีเฟรมพอยน์เตอร์

[GN⁺]

ความเห็นจาก Hacker News

• ประสบการณ์ในช่วงต้นทศวรรษ 2000 ตอนที่การละเว้น stack frame pointer เริ่มแพร่หลาย
  • ผู้เขียนกำลังเรียนวิทยาการคอมพิวเตอร์ในเวลานั้น และคอมพิวเตอร์ที่ใช้ก็เก่าและประสิทธิภาพต่ำ
  • เมื่อการดีบักยากขึ้น จึงเริ่มใช้ Python เพื่อหลีกเลี่ยงปัญหาด้านการดีบัก
• ความพยายามของดิสโทร Fedora ในการคง stack frame pointer ไว้
  • เคยมีความเชื่อที่ผิดว่าการเก็บ stack frame pointer มีโอเวอร์เฮดสูง แต่โอเวอร์เฮดจริงต่ำกว่า 1%
• สิ่งที่ Apple ทำบนสถาปัตยกรรม ARM ซึ่งทำให้ stack trace มีความหมายอยู่เสมอ
  • ฟังก์ชันบางตัวอาจไม่สร้าง frame record แต่ stack trace ก็ยังมีความหมายได้แม้ไม่มีข้อมูลดีบัก
• ประสบการณ์ที่ Google และการถกเถียงกับชุมชนตลอด 20 ปี
  • มีการแบ่งปันประสบการณ์การทำแพตช์และการดูแลรักษาเพื่อนำ libunwind ไปใช้กับ gperftools
• กรณีในอดีตที่เคยเห็นประสิทธิภาพดีขึ้นจากตัวเลือก -fomit-frame-pointer
  • คอมไพล์ MySQL และ PHP บนโปรเซสเซอร์ 32 บิตเพื่อลดต้นทุนฮาร์ดแวร์
• วิธีจัดการ stack frame ของภาษาโปรแกรม Virgil
  • หากไม่มีการจัดสรรสแตกแบบไดนามิก ก็สามารถหาขนาดเฟรมได้ด้วยการค้นตารางอย่างง่าย
  • มีคำอธิบายเกี่ยวกับโค้ดที่ใช้ติดตั้งการถอดรหัส metadata
• ไอเดียการจัดการสองสแตกโดยใช้ RBP และ RSP แทนการ "เดิน" สแตก
  • call stack กลายเป็นเพียงอาร์เรย์ของ return address ทำให้ความจำเป็นในการไล่สแตกลดลง
• การแบ่งปันประสบการณ์และมุมมองที่สนับสนุน frame pointer
  • การเปิดใช้ frame pointer ควรตัดสินใจเป็นกรณีไป และการทำ benchmarking เป็นสิ่งสำคัญ
  • ความสำคัญของการที่ build system มีความสามารถในการเปลี่ยนค่านี้ได้ทั้งระบบ
  • ความคาดหวังต่อ SFrame และศักยภาพในการแก้ปัญหาปัจจุบัน
• ความเห็นว่าปัญหาเรื่อง profiling ยืดเยื้อมานาน 20 ปี และเพิ่งได้รับการแก้ไขในตอนนี้
  • การไม่มี frame pointer สร้างความเจ็บปวดให้หลายคน และตอนนี้เมื่อเห็น Linux นำมันกลับมา ก็เหมือนความพยายามของพวกเขาได้รับการยอมรับ
• ความไม่พอใจต่อประสิทธิภาพของกลไกที่ทำให้ system profiling เป็นไปได้เป็นเรื่องน่าขันในตัวเอง
  • การบ่นเรื่องประสิทธิภาพของระบบที่ช่วยให้ระบุปัญหาด้านประสิทธิภาพได้ คือที่สุดของการทำ optimization ก่อนเวลาอันควร