Linus Torvalds ส่งแพตช์ชุดแรกที่ทำร่วมกับ LLM: ให้ read() อ่าน page cache โดยไม่แตะ refcount เร็วขึ้นราว 3 เท่าเมื่อหลายเธรดอ่านไฟล์เดียวกัน — cover letter ระบุชัดว่าโค้ด เทสต์ และร่างข้อความทำด้วย Claude Code

Linus Torvalds เคยเล่าบนเวที Maintainers Summit ว่ากำลังใช้ LLM แก้ปัญหาเก่าในเคอร์เนล เมื่อ 14 ต.ค. 2026 LWN รายงาน ว่าเขาส่งแพตช์ชุดนั้นเข้ารีวิวแล้ว โค้ดอยู่ใน branch ชื่อ noref-filemap-read-with-llm บน git.kernel.org และคอมมิตลงวันที่ 7–10 ต.ค. เราดึง branch มาอ่านเอง ในนั้นมีแพตช์ 8 ตัว (LWN เขียนว่าชุดที่ส่งเข้า mailing list มี 10 ตัว ตัวเลขอาจต่างกันเพราะเป็นคนละเวอร์ชัน) ทุกตัวมีบรรทัด Assisted-by: LLM อยู่เหนือ Signed-off-by: Linus Torvalds และมีคอมมิตสุดท้ายเป็น cover letter ยาว ซึ่งมีหัวข้อ “Tools” เขียนไว้ตรง ๆ ว่า

“The code, the test programs, the review behind the list above and the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction. The measurements were run on my machine.”

นี่ไม่ใช่การให้ AI ช่วยเติมโค้ดไม่กี่บรรทัด เจ้าของเคอร์เนลใช้เอเจนต์เขียนโค้ดทำแพตช์ชุดใหญ่ในส่วน memory management ซึ่งละเอียดอ่อนที่สุดส่วนหนึ่งของ Linux แล้วติดป้ายบอกชัดในทุกคอมมิต แต่ก็ต้องบอกด้วยว่า LWN รายงานว่า การรีวิวเจอ race condition แล้ว แพตช์ชุดนี้จึงยังต้องแก้ต่อ และยังไม่ได้เข้า mainline

ปัญหาที่แก้: refcount ของ folio กลายเป็นคอขวด

ปัญหานี้ Matthew Wilcox ยกขึ้นมาตั้งแต่ปี 2024 จาก workload ของลูกค้า เวลาหลายเธรดอ่านไฟล์เดียวกันทีละนิด filemap_get_read_batch() จะเพิ่ม reference ของ folio ด้วย lock cmpxchg และ filemap_read() ก็ลดมันลงด้วย lock decl ทุกการอ่านจึงต้องเขียน cache line ของ struct page สองครั้ง Torvalds วัดบนแล็ปท็อป i7-8565U (4 คอร์ / 8 เธรด) ให้ 8 เธรดเรียก pread() ครั้งละ 16 ไบต์จากหน้าเดียวกัน พบว่า cache line นั้นกิน 99.92% ของ load HITM ทั้งหมด

เคยมีคนพยายามแก้แล้ว รวมถึงแพตช์ “fast short reads” ของ Kiryl Shutemov ซึ่งคัดลอกข้อมูลลง buffer บน stack ก่อนแล้วค่อยตรวจย้อนหลัง แต่วิธีนั้นติดกรณีที่การตรวจมองไม่เห็น เช่น หน้าถูกปล่อยแล้วถูกใช้ใหม่ที่ index เดิม การ migrate หน้า หรือการอ่านไปโดนหน่วยความจำที่ไม่ใช่ page cache แล้ว (secretmem, unaccepted memory หรือแม้แต่ MMIO)

วิธีของชุดนี้: เลื่อนการคืนหน้าออกไปหนึ่ง RCU grace period

แนวคิดหลักมีประโยคเดียว คือ folio ที่ถูกเอาออกจาก page cache จะกลับไปที่ page allocator ได้ก็ต่อเมื่อผ่าน RCU grace period ไปแล้ว พอเป็นแบบนี้ หน้าที่ xas_load() เจอภายใต้ rcu_read_lock() ก็รับประกันได้ว่ายังเก็บข้อมูลของไฟล์นั้นอยู่จนกว่าจะ rcu_read_unlock() แล้ว filemap_read() ก็คัดลอกตรงไปยัง buffer ของผู้ใช้ได้เลยโดยปิด page fault ไว้ ไม่ต้องจับ reference ไม่ต้องใช้ bounce buffer ไม่ต้องใช้ seqcount และไม่จำกัดขนาดการอ่าน

แพตช์ทั้ง 8 ตัวแบ่งงานดังนี้: ติด flag PG_rcu_free ตอนที่ folio ออกจาก i_pages แล้วให้ __free_pages_prepare() ส่งหน้านั้นเข้าคิวรายซีพียูแทนการคืนทันที, ไม่เลื่อนการคืนให้ inode ที่กำลังถูก evict (กันกรณี rm ไฟล์ใหญ่ทั้งไฟล์), ตัดการ “ขโมย” หน้า page cache ใน splice ทิ้ง (fuse กับ virtio_console เปลี่ยนไปคัดลอกแทน), เพิ่มตัวนับหน้าที่รอ และถ้าซีพียูไหนมีหน้ารอเกิน 1024 หน้าก็เรียก synchronize_rcu_expedited() (แพตช์ 7–8)

ตัวเลขใน cover letter (แล็ปท็อปเครื่องเดียว, ext4, ปิด mitigations; ให้ดูต้นทุนต่อการอ่าน เพราะเครื่องลดความเร็วเองเมื่อร้อน):

สถานการณ์ (16 ไบต์, ไฟล์เดียว)	kernel cycles ต่อการอ่าน	reads/s
ก่อนแพตช์, 8 เธรด	2,937–2,975	9.9–10.4 ล้าน
หลังแพตช์, 8 เธรด	725–726	30–33 ล้าน
ก่อนแพตช์, 1 เธรด	452–454	7.9–8.1 ล้าน
หลังแพตช์, 1 เธรด	408–409	8.8–8.9 ล้าน

load HITM ลดจาก 30,538 เหลือ 101 ส่วนการอ่าน 64 KiB ด้วย 8 เธรดบนไฟล์เดียวลดจาก ~18,000 เหลือ ~11,000 cycles แต่ไม่ได้เร็วขึ้นทุกกรณี ถ้าอ่านลง user page ที่ยังไม่ถูก map จะเกิด exception ที่ล้มเหลวเพิ่มหนึ่งครั้ง กรณี 16 ไบต์ 1 เธรดจึงช้าลง จาก ~4,150 เป็น ~6,560 cycles

รายการ “สิ่งที่ยังไม่ได้แก้” ยาวกว่าส่วนอื่นของเอกสาร

หัวข้อ “Known problems” มี 10 ข้อ และเป็นส่วนที่น่าอ่านที่สุด ข้อแรกคือ allocator มองไม่เห็นหน้าที่รอคืน หน้าพวกนี้มี refcount 0 แต่ไม่อยู่ในตัวนับใดเลย ใน reproducer ของ Kiryl (VM 2 GiB ไม่มี swap) ถ้าใช้แค่แพตช์ 1–6 OOM killer จะฆ่าโปรเซส ที่ 4 และ 8 ซีพียู แพตช์ 7–8 ทำให้รันจนจบได้ แต่ก็แค่ทำให้คิวสั้นลง ไม่ได้ทำให้ allocator มองเห็นหน้าเหล่านั้น ค่า 1024 หน้าก็เป็น “การเดา” และตอนไม่มีซีพียูว่าง (N = 16) ยังมีหน่วยความจำรอเฉลี่ย 177 MiB และสูงสุดถึง 870 MiB

ข้ออื่น ๆ ได้แก่ alloc_contig_range() ล้ม ทำให้ CMA ถดถอย, ต้องใช้ page flag เพิ่มอีกหนึ่งตัว, s390 ยังไม่ได้คิด, แพตช์ 7 เรียก synchronize_rcu_expedited() 4,600 ครั้งต่อวินาทีทั้งที่ kernel-doc ห้ามเรียกในลูป และยังไม่ได้ทดสอบ xfstests, lockdep, KASAN, เคอร์เนลที่ link ด้วย clang, เครื่อง 32 บิต หรือเครื่องอื่นนอกจากแล็ปท็อปตัวนี้เลย เขาเขียนไว้เองว่า “Those … are all the testing there is.”

มุมมอง AI Curator

ข่าวนี้จะถูกเล่าเป็น “Linus ใช้ AI แล้ว” แต่สิ่งที่นักพัฒนาควรดูคือรูปแบบการทำงาน Torvalds ไม่ได้สั่งให้เอเจนต์ “ทำให้ read เร็วขึ้น” แล้วส่งผลลัพธ์ทั้งก้อน เขากำหนดแนวคิดเอง (เลื่อนการคืนหน้า ไม่เลื่อนการตัด reference) แล้วให้เอเจนต์เขียนโค้ด เขียนโปรแกรมทดสอบ และไล่หาจุดอ่อน สุดท้ายสิ่งที่ส่งออกมาคือ cover letter ที่บอกตรง ๆ ว่ายังไม่ได้ทดสอบอะไรบ้าง วัดบนเครื่องไหน และให้ผู้รีวิวช่วยดูตรงไหน รายการ known problems 10 ข้อนั้น (ซึ่งเขาบอกว่าเอเจนต์ช่วย “review”) มีค่าต่อผู้รีวิวมากกว่าตัวเลข 3 เท่าเสียอีก ผลก็คือผู้รีวิวเจอ race condition ได้เร็ว เพราะรู้ว่าต้องดูตรงไหน

สำหรับทีมไทยที่กำลังร่างนโยบาย AI-assisted contribution ตัวอย่างนี้ใช้เป็นแม่แบบได้เลย คือติด trailer Assisted-by: ในทุกคอมมิต ระบุเครื่องมือในคำอธิบาย PR แยกให้ชัดว่าส่วนไหนคนวัดเอง และเขียนรายการ “ยังไม่ได้ทดสอบ” ให้ยาวพอ ๆ กับรายการที่ทดสอบแล้ว ประเด็นที่ควรจำคือคุณภาพไม่ได้มาจากการที่เอเจนต์เขียนเก่ง มันมาจากการที่คนกำกับรู้ว่าโค้ดชุดนี้ยังพิสูจน์อะไรไม่ได้ และกล้าบอกออกมา ส่วนจะเข้า 7.4 หรือไม่ ขึ้นกับว่าปัญหา allocator มองไม่เห็นหน้าที่รอคืนจะแก้ได้หรือไม่ ไม่ได้ขึ้นกับว่าใครหรืออะไรเป็นคนพิมพ์โค้ด

แหล่งข่าว

• LWN.net — Linus Torvalds’s first LLM-assisted patch series (14 ต.ค. 2026)
• git.kernel.org — branch noref-filemap-read-with-llm (cover letter + 8 แพตช์)