Meta geliştiricisi, Torvalds'ın yapay zekâyla yazdığı page-cache yamalarını 4,5 kat ext4 kazançlı 18 yamalık RFC'ye dönüştürdü

Linus Torvalds'ın LLM üretimi çekirdek kodu deneyi posta listesine ulaştı

19 Ekim'de Meta çekirdek geliştiricisi Kiryl Shutsemau, LKML'ye Torvalds'ın bir LLM ile yazdığı on yamayı yeniden düzenleyip genişleten 18 yamalık bir RFC serisi gönderdi; kıyaslamalar ext4'te yaklaşık 4,5 kat hızlı okuma gösteriyor. Raporu dev.to'nun yeniden yayınladığı Joho no Todai'ye göre, git dalından incelenebilir bir seriye geçiş altı gün sürdü.

Git dalından RFC'ye

Torvalds yamalarını yaklaşık bir hafta önce posta listesi gönderisi olarak değil, bir git dalı olarak yayınladı. Yamalar page-cache okuma ölçeklenebilirliğini hedefliyor ve saniyedeki okuma işlemi sayısını 64 iş parçacığıyla 13,3 milyondan 304 milyona, yani kabaca 23 kat artırıyordu; ancak Torvalds bu rakamın, her CPU'nun aynı dosyanın aynı ofsetini tekrar tekrar okuduğu bir stres testinden geldiğini kabul etti.

Bu çalışmanın kendi revizyonlarını Ekim 2025'te göndermiş olan Shutsemau, dalı resmî bir teklife dönüştürdü: Torvalds'ın on yaması yeniden düzenlendi, artı olarak kendisinin eklediği on bir yama geldi. Torvalds'ın yazdığı yedi yamada "Assisted-by: LLM" etiketi taşıyor.

Yamalar neyi değiştiriyor

Linux bir dosyayı okuduğunda, veri page cache'te folio'lar halinde durur ve her okuma, dokunduğu her folio için bir referans alıp bırakmak zorundadır. Bu güncellemeler atomik talimatlar olduğu için, düzinelerce CPU aynı sıcak folio'ya çarptığında sayacı tutan cache line çekirdekler arasında ping-pong oynar ve verim çöker. tmpfs durumu daha kötüydü: Her okuma ayrıca bir folio kilidi alıyordu, bu yüzden yamalardan önce 64 iş parçacığı tek bir iş parçacığından hızlı çalışmıyordu.

Seri, sık erişilen folio'lar için sayacı devre dışı bırakıyor. Yeni PG_rcu_free bayrağıyla işaretlenmiş bir folio, boşaltıldıktan sonra bir RCU grace period — yani tüm CPU'ların mevcut işlerini bitirdiği pencere — geçmeden yeniden kullanılmıyor. Bu pencere içinde okuyucular veriyi referans sayacına hiç dokunmadan kopyalayabiliyor. Akış okumaları ve yalnızca bir kez okunan veri bu bayrağı almıyor; bu da ertelenen boşaltmanın tuttuğu belleği küçük tutuyor diye bildiriliyor.

Rakamlar

Kıyaslamalar, Linux 7.3-rc7 tabanlı olarak, AMD Ryzen Threadripper 7975WX üzerinde 64 sanal CPU'lu bir KVM konuğunda çalıştırıldı. Manşet test, 64 iş parçacığını 0 ofsetinde 16 baytlık pread() çağrılarından geçirdi; her biri kendi dosya tanımlayıcısına sahipti.

Varsayılan CPU güvenlik açığı azaltmaları etkinken ext4 saniyede yaklaşık 15 milyon işlemden 68,9–70,1 milyona, kabaca 4,5 kat yükseldi; tmpfs ise 1,6–1,7 milyondan 71–72 milyona yaklaşık 43 kat sıçradı. Azaltmalar kapatıldığında ext4 saniyede 217–220 milyon işleme, yaklaşık 13 kata ulaştı; kapak mektubu, sonuçları sınırlayan şey olarak varsayılan azaltmalar altında her okuma başına yaklaşık 400 nanosaniyelik kullanıcı/çekirdek geçiş yükünü gösteriyor: TSA için yaklaşık 170 ns ve SRSO için 230 ns.

XFS ve blok aygıtları daha mütevazı, sırasıyla 1,8 kat ve 2 kat iyileşti; çünkü ikisi de her okumada hâlâ paylaşımlı bir i_rwsem kilidi alıyor. 64 KB büyük-folio testlerinde tmpfs 96–100k'dan 1370–1390k MiB/s'ye, ext4 ise 756–775k'dan 1355–1373k MiB/s'ye yükseldi. Tek iş parçacıklı okumalarda ise belirgin bir değişiklik olmadı.

Hâlâ bir RFC

Yamalar RFC olarak işaretlendi — yani tasarım hakkında geri bildirim isteği, birleştirme için başvuru değil — ve kapak mektubu yedi çözülmemiş sorun listeliyor. Bunlar arasında: PG_rcu_free yalnızca 64 bitlik sistemlerde var ve büyük yapılandırmalarda MGLRU'nun ihtiyaç duyduğu bir referans bitini tüketiyor; grace period'u bekleyen folio'lar hiçbir memcg'ye yüklenmiyor; ve compaction sonrasında pageblock boşaltması gecikiyor.

Sorunun kaynağı tüm bunlardan daha eski: Matthew Wilcox, page-cache referans saymayı yıllar önce buffered-I/O ölçeklenebilirlik sınırı olarak tanımlamıştı ve hem Shutsemau hem de Ilya Gladyshev —后者 altı revizyon boyunca — daha önce çözüm peşinde koşmuştu.

Neden önemli

Seri, yapay zekâ destekli çekirdek geliştirmesi için çarpıcı bir veri noktası: Bir LLM başlangıç noktasını üretti ve altı gün içinde insan bir geliştirici bunu posta listesinin gerçekten inceleyebileceği bir şeye dönüştürdü. Ayrıca gerçek ve köklü bir darboğazı hedefliyor; tmpfs sonucu — fiilen hiç iş parçacığı ölçeklenmesinden tam paralelliğe — geride bırakılan performansın ne kadar fazla olduğunu gösteriyor.

Ancak "Assisted-by: LLM" etiketi LKML'de hiçbir ağırlık taşımıyor. Joho no Todai'nin deyişiyle, seri şimdi yalnızca tasarım ve kod kalitesine göre değerlendirilecek ve onu ana çekirdekten ayıran yedi açık sorun bulunuyor.