Linux’un yaratıcısı ve çekirdek geliştirmesinin baş sorumlusu Linus Torvalds, dosya okuma yolunda iki yıldan uzun süredir devam eden bir darboğazın giderilmesine yardımcı olması için Anthropic’in Claude Code aracını kullandı. 10 yamadan oluşan seri, 64 çekirdekli bir Threadripper üzerinde yapılan sentetik bir testte okuma hızında 23 kata varan artış sağladı; ancak Linux çekirdeği incelemecileri daha sonra bir yarış durumu tespit etti ve bellek geri kazanımı tasarımının güvenliğiyle ilgili sorular yöneltti. Bu da yamaların henüz birleştirilmediği anlamına geliyor.
Sayfa belleği referans sayaçlarındaki sorun
Çalışma, verilere erişimi hızlandırmak için dosyalardan okunan verileri tutan bir katman olan page cache içindeki folio adı verilen nesnelerin referans sayaçları üzerindeki rekabetle ilgili. Darboğaz, bir müşterinin iş yükünde ortaya çıkmasının ardından 2024’te bildirildi. Torvalds’ın dizüstü bilgisayarında yapılan testler, sekiz iş parçacığı kullanan bir testte bu rekabetin çekirdekler arasındaki HITM işlemlerinin %99,92’sini oluşturduğunu gösterdi.
Torvalds, sorun için daha önceki düzeltmesinin kusurlu bir sürümünü 18 ay boyunca çalıştırdığını, diğer geliştiricilerin ise kendi girişimlerinde sorunlarla karşılaştığını söyledi. Yeni yamalar, en sık kullanılan önbellekli okuma yolundaki folio referanslarını artırma ve azaltma işlemlerini kaldırmayı hedefliyor. Torvalds ise gerçek iş yüklerinde kazanımların sentetik teste kıyasla çok daha küçük olacağı konusunda uyardı.
Claude Code’un rolü ve sonucun sınırları
Torvalds’ın ağacında noref-filemap-read-with-llm adlı deneysel bir dal ortaya çıktı; ardından seri, Claude Code’un rolüne ilişkin bir açıklama içerdi. Torvalds’ın aktardığına göre araç, uygulamayı, testleri ve ilk belgeleri yazdı; ayrıca onun yönlendirmesi altında kodu inceledi. Performans testlerini ise kendisi çalıştırdı.
İlk seri, dizüstü bilgisayarındaki okuma hızını saniyede yaklaşık 10 milyondan 33 milyon okumaya çıkardı ve okuma başına çekirdek döngüsü sayısını yaklaşık 2.950’den 725’e düşürdü. Düzeltilmiş seri ise Threadripper üzerinde yüksek yük altında performansı saniyede 13,3 milyon okumadan 304 milyon okumaya çıkardı; okuma başına döngü sayısı da yaklaşık 20.000’den 735’e düştü.
Performans rakamları neden yeterli değil?
İyileşme, olası maliyetlerle birlikte geldi. İlk uygulama, CPU 1.024 ertelenmiş geri kazanım sayfasını aştığında zorunlu bir bekleme süresi uyguluyordu. Ayrıca ilişkilendirilmemiş kullanıcı sayfalarına yapılan okumalar, mevcut yola dönmeden önce ek bir hataya neden oldu; bu da tek iş parçacıklı 16 baytlık okumanın maliyetini yaklaşık 4.150 döngüden 6.550 döngüye çıkardı. Bu gerilemenin rcu-free-v3 sürümünde kalıp kalmayacağı henüz netleşmedi.
İnceleme en önemli riski ortaya çıkardı
Matthew Wilcox, yeni PG_rcu_free bayrağının kullanılmasına itiraz etti ve sayfa türüne dayanan, etkin olmayan folio’ların geri kazanılması için farklı bir mekanizma kullanan bir alternatif önerdi. Kiryl Shutsemau da bayrağın yalnızca 64 bit sistemlerle sınırlandırılmasını önerdi; David Hildenbrand bu yaklaşımı destekledi.
Shutsemau ayrıca filemap_read_rcu_batch() işlevinde bir yarış durumu tespit etti: Bir folio’nun değiştirilmesi ve ardından dosya boyutunun genişletilmesi, gerçekte yazılmamış verilerin görünür olmasına yol açabilir. Torvalds, dosya boyutunun daha erken okunmasını ve denetim işlemlerinin bir araya getirilmesini önerdi; bu değişiklik gözden geçirilmiş bir yamaya eklendi.
certi.news’un editoryal değerlendirmesi: Bu durum, yapay zekâ ile programlama araçlarının çekirdek testlerinde büyük iyileştirmelere hızla ulaşabildiğini, ancak eşzamanlılık ve bellek yaşam döngüsünü anlayan uzman incelemesine duyulan ihtiyacı ortadan kaldırmadığını gösteriyor. Buradaki rekor rakamlar belirli bir ortamdaki kazanımı kanıtlıyor; otomatik olarak birleştirilmeye hazır olunduğunu veya uygulamanın güvenli olduğunu garanti etmiyor.