Linux borularında performans düşüşü

vmsplice aşırı hızlı

• Bazı programlar, veriyi borular üzerinden daha hızlı taşımak için vmsplice adlı bir sistem çağrısı kullanır
• vmsplice kullanılmadığında Linux borularının beklenenden daha yavaş olduğu fark edildi
• Morse kodunu hızlı biçimde kodlayıp çözen bir program yazılıyor ve bunun için borular kullanılıyor

İdeal koşullarda veri yazma

• Aşağıdaki program, sistem çağrısı olmadan veriyi kopyalar
• AVX-512 kullanarak 167 GB/s hızda çalışır
• AVX-512 devre dışı bırakılıp AVX2 ve SSE2 ile test edildiğinde de aynı hız (167 GB/s) elde edildi
• Vektörleştirme kullanıldığı sürece 167 GB/s hızına ulaşılabiliyor

Gerçekte boruya veri yazma

• Boruya veri yazan bir program yazılıp ölçüldüğünde 17 GB/s hız elde edildi
• Bu, bir arabelleğe yazmaktan 10 kat daha yavaş
• Profilleme sonuçlarına göre zamanın büyük kısmı write çağrısında harcanıyor
• pipe_write fonksiyonunda bellek sayfaları ayırmak çok zaman alıyor
• Verinin kopyalanması CPU süresinin yalnızca %20'sini kaplıyor, ama yine de __memset_avx512_unaligned_erms'den iki kat daha yavaş

vmsplice yardımı

• vmsplice, kullanıcı alanındaki arabelleği çekirdeğe kopyalamak yerine taşır
• vmsplice kullanıldığında 210 GB/s hıza ulaşılabiliyor
• vmsplice, write sistem çağrısının pahalı kısımlarını baypas eder

Sonuç

• Boruya yazmak, ham belleğe yazmaktan 10 kat daha yavaş
• Bunun nedeni, arabelleği kilitlemenin maliyeti ile SIMD bağlamını kaydedip geri yüklemenin maliyetidir
• splice ve vmsplice, bu maliyetlerden kaçınıp veriyi verimli şekilde taşır

GN⁺ özeti

• Bu yazı, Linux borularında performansı en üst düzeye çıkarmak için vmsplice kullanmayı açıklıyor
• vmsplice, veriyi çekirdek alanına kopyalamadan doğrudan taşıyarak performansı ciddi biçimde artırıyor
• Morse kodu kodlama/çözme gibi yüksek hızlı veri işleme programlarında faydalı
• Benzer işlevlere sahip diğer projeler arasında splice ve sendfile bulunuyor

[GN⁺]

Hacker News görüşleri

• JMP'nin RET ile değiştirilmemesinin nedeni CONFIG_RETHUNK seçeneği

  • objdump disassembly çıktısında RET'in JMP __x86_return_thunk ile değiştirildiğini görebilirsiniz
  • İlgili bağlantılar: link1, link2

• Fonksiyonun başındaki ve sonundaki NOP komutları, ftrace'in izleme komutları ekleyebilmesini sağlıyor

  • ASM_CLAC ve ASM_STAC makrolarından geliyor
  • X86_FEATURE_SMAP algılanırsa çalışma zamanında CLAC ve STAC komutlarıyla dolduruluyor
  • İlgili bağlantılar: link3, link4, link5

• Bir kullanıcının yan projesi, dosya tanımlayıcıları için ring buffer sağlayan bir sistem çağrısı öneriyor

  • Pipe'ın iki ucu da ring buffer'ı destekliyorsa aynı ring buffer eşlenerek kernel çağrısı olmadan zero-copy IO mümkün oluyor
  • İşbirlikçi arıyor
  • İlgili bağlantı: link6

• Linux pipe'ına "yavaş" demek, Toyota Corolla'ya "yavaş" demek gibi

  • Çoğu durumda yeterince hızlı
  • Uç durumlarla uğraşmıyorsanız daha hızlı bir şey aramanıza gerek yok

• Modern CPU'larda rep movsb, en hızlı vektörleştirilmiş sürüm kadar hızlı

  • Kernel fonksiyon adı "copy_user_enhanced_fast_string" buna işaret ediyor
  • Bunu mümkün kılan CPU özellikleri ERMS ve FSRM

• AVX512 çok güç tüketiyor ve CPU frekans ölçeklemesini tetikliyor

  • İlgili bağlantılar: link7, link8

• Hacker News'in "hug of death" etkisi yeniden yaşanıyor

  • Önbelleğe alınmış WordPress sayfaları sayesinde durum daha iyi ama yine de birkaç saniye sürüyor

• io_uring kullanan bir sürümü görmek ilginç olurdu

  • Kernel ile önceden paylaşılan buffer'lar kullanarak kopyalamadan kaçınılabilir ve sistem çağrısı ek yükü azaltılabilir

• Blogun yüklenmesinin yaklaşık 20 saniye sürmesi epey iddialı bir ifade

• IPC'nin neredeyse her türü "yavaş"

  • Güvenlik için performans maliyeti ödemeyi seçtik

• Başta splice'ın neden bu kadar yavaş olduğunu anlamamıştım

  • vmsplice'tan neden daha yavaş olduğu belirtilmişti ama neden olduğu net değildi
  • vmsplice ile yeniden uygulanamamasının bir nedeni olmalı