Operasi receive yang blocking di Linux biasanya tidur saat belum ada data yang siap, lalu berjalan kembali setelah jalur networking menyediakan data. Dengan SO_BUSY_POLL, jalur receive dapat memakai interval terbatas untuk aktif melakukan polling pada konteks NAPI yang relevan. Interval ini menukar waktu CPU dengan peluang memproses paket sebelum jalur normal berbasis interrupt membangunkan task.
Opsi ini tidak mengubah socket menjadi endpoint yang terus-menerus melakukan polling. Nilainya menentukan budget busy poll dalam mikrodetik, sedangkan mekanismenya tetap bergantung pada riwayat receive dan dukungan perangkat jaringan.
Socket menyimpan budget waktu busy poll
SO_BUSY_POLL dikonfigurasi dengan nilai integer yang menyatakan perkiraan durasi busy poll dalam mikrodetik. Linux menambahkan opsi socket ini pada versi 3.11. Nilai bawaan sistem untuk pembacaan socket tersedia melalui net.core.busy_read, sedangkan konfigurasi per socket dapat menggantikan nilai bawaan tersebut.
int usecs = 50;
if (setsockopt(fd, SOL_SOCKET, SO_BUSY_POLL,
&usecs, sizeof(usecs)) == -1) {
/* handle error */
}Nilai tersebut adalah budget waktu polling, bukan receive timeout. Receive timeout membatasi berapa lama operasi blocking dapat menunggu sebelum melaporkan kondisi timeout. Busy polling mengubah aktivitas kernel selama sebagian waktu tunggu itu: kernel dapat menjalankan polling sisi receive alih-alih langsung bergantung pada interrupt berikutnya dan scheduler wakeup.
Dokumentasi Linux menyebut durasinya sebagai perkiraan. Scheduling, perilaku driver, status NAPI, waktu kedatangan traffic, dan detail implementasi kernel membuat nilai tersebut tidak dapat diperlakukan sebagai deadline latensi yang presisi.
Busy polling masuk ke pemrosesan paket NAPI
NAPI adalah mekanisme networking Linux yang mengoordinasikan pemrosesan paket antara notifikasi perangkat dan polling. Dalam operasi normal, perangkat jaringan dapat memberi tahu host melalui interrupt, kemudian pemrosesan NAPI menangani pekerjaan yang mengantre. Busy polling menyediakan jalur masuk lain: task user space yang menunggu input jaringan dapat memicu polling sebelum interrupt perangkat terjadi.
Jalur ini bersifat kondisional. Socket harus sebelumnya menerima data dari perangkat jaringan yang mendukung busy polling. Kernel memakai state sisi receive yang terkait dengan socket untuk menentukan konteks polling yang relevan; memasang nilai bukan nol pada sembarang socket tidak menjamin ada pekerjaan perangkat yang berguna untuk dipolling.
Batas ini juga memisahkan SO_BUSY_POLL dari semantik protokol. Ordering TCP, retransmission, congestion control, dan perilaku byte stream tetap sama. Batas datagram UDP juga tetap sama. Opsi tersebut memengaruhi waktu pemrosesan sisi receive dapat dijalankan, bukan protokol di jaringan atau framing aplikasi.
Polling dapat memangkas jalur wakeup tetapi memakai waktu eksekusi
Jalur receive berbasis interrupt dapat melibatkan pengiriman interrupt perangkat, scheduling NAPI, pemrosesan paket, antrean socket, dan task wakeup sebelum aplikasi kembali berjalan. Busy polling dapat memproses paket ketika aplikasi masih aktif di jalur receive sehingga sebagian waktu tunggu dan wakeup dapat dihindari pada kondisi yang sesuai.
Biayanya adalah konsumsi CPU yang disengaja selama paket belum tersedia. Dokumentasi kernel Linux menjelaskan NAPI busy polling sebagai pertukaran siklus CPU untuk latensi yang lebih rendah, sedangkan manual socket memperingatkan kenaikan penggunaan CPU dan daya. Budget yang lebih panjang karena itu bukan peningkatan tanpa syarat.
Titik operasi yang sesuai bergantung pada laju kedatangan paket, target latensi, isolasi CPU, batas daya, perilaku NIC dan driver, serta persaingan dengan pekerjaan lain yang siap berjalan. Layanan sensitif latensi pada CPU khusus memiliki batas biaya berbeda dari host padat yang menjadikan waktu idle CPU dan daya sebagai sumber daya penting.
Read dan readiness wait memiliki kontrol yang berkaitan
Opsi per socket berlaku langsung pada receive yang blocking. Linux juga menyediakan net.core.busy_poll untuk busy polling pada readiness wait seperti poll() dan select() ketika socket yang memenuhi syarat mengaktifkan SO_BUSY_POLL. Antarmuka NAPI saat ini juga menyediakan konfigurasi busy poll yang berorientasi pada epoll.
Kontrol tersebut tidak memiliki satu jaminan semantik yang identik. Budget receive per socket, pengaturan sistem untuk readiness polling, dan parameter NAPI epoll yang lebih baru memengaruhi bagian yang berkaitan pada jalur receive, tetapi bekerja melalui antarmuka berbeda.
Aplikasi berbasis event loop juga tetap memiliki semantik readiness normal. Busy polling dapat membuat pemrosesan paket berlangsung selama operasi wait, tetapi notifikasi readiness tetap melaporkan keadaan I/O saat itu dan tidak mencadangkan data untuk thread tertentu.
Dukungan perangkat dan konfigurasi kernel membatasi efek
Kernel harus dibangun dengan dukungan receive busy poll, dan jalur jaringan harus menyediakan konteks NAPI yang dapat digunakan. Kontrol sysctl yang terdokumentasi tidak menghasilkan mekanisme latensi tersebut jika prasyarat ini tidak tersedia. Lapisan jaringan virtual, pilihan driver, dan topologi deployment juga dapat mengubah konteks NAPI yang terkait dengan traffic masuk.
Privilege menjadi batas lain. Manual socket menyatakan bahwa peningkatan nilai SO_BUSY_POLL memerlukan CAP_NET_ADMIN. Perangkat lunak karena itu perlu memperlakukan kegagalan konfigurasi sebagai kondisi operasional yang mungkin terjadi, bukan menganggap budget yang diminta pasti terpasang.
Nilai yang berhasil dikonfigurasi juga tidak membuktikan penurunan latensi. Nilai itu hanya membuktikan bahwa aplikasi meminta mekanisme kernel yang efeknya bergantung pada waktu kedatangan paket dan jalur jaringan aktif.
Pertukaran latensi berada pada batas scheduling receive
SO_BUSY_POLL paling tepat diperlakukan sebagai kebijakan scheduling receive. Opsi ini mengizinkan kerja aktif yang dibatasi waktu pada titik ketika task dapat memilih menunggu progres berbasis interrupt. Jalur tersebut dapat memperpendek latensi ketika paket tiba di dalam jendela polling dan perangkat memenuhi syarat, dengan biaya siklus CPU setiap kali polling tidak menemukan pekerjaan yang berguna.
Mekanismenya lebih sempit daripada sakelar latensi rendah yang berlaku umum. Nilainya muncul ketika budget polling disesuaikan dengan workload yang terukur dan jalur NAPI yang kompatibel, sambil menghitung biaya CPU serta daya bersama latensi receive.