Linux pipe'larının hızı ne kadar yüksek? (2022)

• Unix pipe'larının Linux'taki uygulamasını ve pipe üzerinden veri yazıp okuyan test programlarının nasıl optimize edileceğini inceliyor
• İlk program yaklaşık 3.5GiB/s aktarım hızına sahipti ve çeşitli optimizasyonlarla bu değer 20 kat artırıldı
• Bu optimizasyonlar, Linux'un perf aracıyla programın profillenmesi sayesinde gerçekleştirildi
• Yazı, pipe'a yaklaşık 35GiB/s hızla çıktı iten optimize edilmiş bir FizzBuzz programından ilham alıyor
• Pipe'ların iç çalışma biçimini, onlara yazmanın ve onlardan okumanın neden yavaş olduğunu ve vmsplice ile splice sistem çağrılarının performansı nasıl artırabildiğini derinlemesine ele alıyor
• Linux sayfalaması ile huge page kullanımının programın daha hızlı sürümlerine nasıl yol açabileceğini tartışıyor
• Son optimizasyon, polling'i yoğun bir döngüyle değiştirmeyi içeriyor
• Testler Intel Skylake i7-8550U CPU ve Linux 5.17 üzerinde gerçekleştirildi
• Yazı, belleğin sabit boyutlu page'lerden nasıl oluştuğunu ve CPU'nun page table'ları kullanarak sanal adresleri fiziksel adreslere nasıl çevirdiğini ayrıntılı biçimde açıklıyor
• Yazı, programda huge page'lere geçmenin performansı yaklaşık %50 artırdığı gözlemiyle sonuçlanıyor
• Yazı, CPU'da huge page kullanımını ve Translation Lookaside Buffer (TLB) miss'lerini azaltma yöntemlerini tartışıyor; bunlar performansı artırabiliyor
• Çekirdek kodu, struct page'in mevcut mimarinin standart boyutlu page'ini işaret ettiğini varsayıyor. Huge page'ler için, "head" struct page gerçek fiziksel page hakkındaki bilgileri içerirken, ardışık "tail" page'ler yalnızca head page'e işaret eden pointer'ları içeriyor
• Yeni çekirdekler (5.17 sonrası), head page'i açıkça tanımlayan yeni bir tür olan struct folio içeriyor. Bu, çalışma zamanında bir struct page'in head mi tail mi olduğunu kontrol etme ihtiyacını azaltarak performansı iyileştiriyor
• Yazı, senkronizasyon maliyetinden kaçınmak için yoğun döngü kavramını tartışıyor. Bu yaklaşım, pipe'a yazılamadığında vmsplice'ın geri dönmesini ister ve hazır olana kadar yoğun döngü çalıştırır. Bu yaklaşık %25 performans artışı sağlayabilir, ancak vmsplice hazır olana kadar bir CPU çekirdeğini tamamen meşgul etme maliyeti vardır
• Yazar, yazıda ele alınan başlıca konuları özetliyor: zero-copy işlemler, ring buffer, sayfalama ve sanal bellek, senkronizasyon ek yükü
• Yazar ayrıca, alakasız oldukları ya da ilgi duymadığı için yazıda ele alınmayan başka birçok seçenek ve ayrıntı olduğunu da kabul ediyor
• Yazı, okuyucular tarafından faydalı ve ilgi çekici bulunduğu için olumlu karşılandı

[GN⁺]

Hacker News görüşleri

• Linux pipe'larının hızıyla ilgili bir yazı; iki süreç arasında mini bir paylaşımlı bellek mekanizması gibi çalışan vmsplice'a odaklanıyor
• vmsplice kullanımı, okuma ve yazma sırasında buffer'ların dikkatli yönetilmesini gerektiriyor; karmaşık olsa da verimli olabilir
• Linux pipe'larının standart uygulamasının, en iyi olası hızdan 20 kat daha yavaş olduğu bildiriliyor
• Yazı iyi karşılanıyor ve okurlar bilgilendirici niteliğini övüyor
• Bir okur, Linux pipe'larının deterministik davranış üretebildiğini belirtiyor ve ek okuma için harici kaynak bağlantısı paylaşıyor
• Pipe, socket, file ve memory üzerinde soyutlama sağlayan veri işleme kütüphaneleri hakkında bir soru gündeme geliyor; bunların yazıda tartışılan optimizasyonları uygulayıp uygulamadığı konuşuluyor
• Yazıda splice() ve vmsplice() gibi API'lerden söz ediliyor; bunların çoğu programda kullanımının zor olduğu ve bu yüzden yeterince kullanılmadığı belirtiliyor
• Linux pipe'larının hızı, sistem içindeki tek bir çekirdeğin hızıyla karşılaştırılıyor; kernel, aynı fiziksel bellek sayfasını bir programın stdout'undan diğerinin stdin'ine eşleyerek işlemi zerocopy ya da daha az optimize durumlarda hızlı bir onecopy haline getiriyor
• Yazı, page table kavramını perf ile yapılan performans analizine bağlıyor ve bunun throughput açısından önemini vurguluyor
• Bir okur, Cygwin pipe uygulamasıyla ilgili deneyimini paylaşıyor ve Linux'a kıyasla daha yavaş olduğunu belirtiyor
• Linux pipe'larının hızının cat, sed, awk, cut, grep, uniq, jq gibi komutları tekrar tekrar kullanıp birleştirmek için yeterli olduğu düşünülüyor