Penurunan Performa Pipe Linux

vmsplice terlalu cepat

• Beberapa program menggunakan system call bernama vmsplice untuk memindahkan data melalui pipe dengan lebih cepat
• Ditemukan bahwa pipe Linux lebih lambat dari yang diperkirakan ketika tidak menggunakan vmsplice
• Sedang menulis program untuk mengenkode/dekode kode Morse dengan cepat, dan menggunakan pipe untuk itu

Menulis data dalam kondisi ideal

• Program di bawah ini menyalin data tanpa system call
• Berjalan pada kecepatan 167 GB/s menggunakan AVX-512
• Saat AVX-512 dinonaktifkan dan diuji dengan AVX2 serta SSE2, kecepatannya tetap sama (167 GB/s)
• Selama vektorisasi digunakan, kecepatan 167 GB/s bisa dicapai

Benar-benar menulis data ke pipe

• Setelah menulis dan mengukur program yang menulis data ke pipe, tercatat kecepatan 17 GB/s
• Ini 10 kali lebih lambat dibanding menulis ke buffer
• Hasil profiling menunjukkan sebagian besar waktu dihabiskan pada pemanggilan write
• Banyak waktu dihabiskan untuk mengalokasikan halaman memori di fungsi pipe_write
• Penyalinan data itu sendiri hanya memakan 20% waktu CPU, tetapi tetap dua kali lebih lambat daripada __memset_avx512_unaligned_erms

Bantuan dari vmsplice

• vmsplice memindahkan buffer dari user space ke kernel tanpa menyalinnya
• Dengan vmsplice, kecepatan 210 GB/s dapat dicapai
• vmsplice melewati bagian mahal dari system call write

Penutup

• Menulis ke pipe 10 kali lebih lambat daripada menulis ke memori mentah
• Hal ini disebabkan oleh biaya mengunci buffer serta menyimpan dan memulihkan konteks SIMD
• splice dan vmsplice menghindari biaya ini dan memindahkan data secara efisien

Ringkasan GN⁺

• Artikel ini menjelaskan cara memaksimalkan performa pipe Linux dengan menggunakan vmsplice
• vmsplice sangat meningkatkan performa dengan memindahkan data secara langsung tanpa menyalinnya ke ruang kernel
• Berguna untuk program pemrosesan data berkecepatan tinggi seperti enkode/dekode kode Morse
• Proyek lain dengan fungsi serupa antara lain splice dan sendfile

[GN⁺]

Komentar Hacker News

• Alasan JMP tidak digantikan dengan RET adalah karena opsi CONFIG_RETHUNK

  • Dalam disassembly objdump, bisa dilihat hasil RET yang digantikan menjadi JMP __x86_return_thunk
  • Tautan terkait: tautan1, tautan2

• Instruksi NOP di awal dan akhir fungsi memungkinkan ftrace menyisipkan instruksi pelacakan

  • Berasal dari makro ASM_CLAC dan ASM_STAC
  • Jika X86_FEATURE_SMAP terdeteksi, pada runtime akan diisi dengan instruksi CLAC dan STAC
  • Tautan terkait: tautan3, tautan4, tautan5

• Side project seorang pengguna mengusulkan system call yang menyediakan ring buffer untuk file descriptor

  • Jika kedua ujung pipe mendukung ring buffer, ring buffer yang sama bisa dipetakan sehingga zero-copy IO dimungkinkan tanpa pemanggilan kernel
  • Sedang mencari kolaborator
  • Tautan terkait: tautan6

• Menyebut pipe Linux "lambat" itu seperti menyebut Toyota Corolla "lambat"

  • Dalam kebanyakan kasus sudah cukup cepat
  • Kecuali untuk kasus yang ekstrem, tidak perlu mencari sesuatu yang lebih cepat

• Pada CPU modern, rep movsb secepat versi tervectorisasi yang paling cepat

  • Nama fungsi kernel "copy_user_enhanced_fast_string" mengisyaratkan hal ini
  • Fitur CPU ERMS dan FSRM yang memungkinkan hal tersebut

• AVX512 boros daya dan memicu penskalaan frekuensi CPU

  • Tautan terkait: tautan7, tautan8

• Sedang kembali mengalami "hug of death" dari Hacker News

  • Berkat halaman WordPress yang di-cache, situasinya membaik, tetapi tetap memerlukan beberapa detik

• Menarik untuk melihat versi yang menggunakan io_uring

  • Dengan kernel dan buffer yang dibagikan sebelumnya, penyalinan bisa dihindari dan overhead system call bisa dikurangi

• Klaim bahwa waktu muat blog sekitar 20 detik adalah pernyataan yang berani

• Hampir semua bentuk IPC itu "lambat"

  • Diputuskan untuk membayar biaya performa demi keamanan

• Awalnya tidak mengerti mengapa splice bisa selambat itu

  • Sudah ditunjukkan alasan mengapa lebih lambat daripada vmsplice, tetapi belum jelas mengapa bisa begitu
  • Pasti ada alasan mengapa ini tidak bisa diimplementasikan ulang dengan vmsplice