Wawancara Linux: Bagaimana Cara Anda Menjelaskan dan Mendiagnosis Latensi Penjadwalan CPU?

Konteks Pertanyaan dan Peran yang Relevan

Sebuah server dengan 16 vCPU yang menjalankan Linux 6.12 dan cgroup v2 menghosting API yang sensitif terhadap latensi bersamaan dengan job kompresi offline. Setelah job offline dimulai, p99 API melonjak dari 45ms ke 600ms. Monitoring host melaporkan sekitar 78% utilisasi CPU agregat, dan API mengakumulasi sedikit waktu CPU. Thread API dan job offline yang relevan semuanya menggunakan SCHED_OTHER.

Jelaskan bagaimana fair scheduler Linux modern memilih di antara thread yang runnable, kemudian berikan proses diagnostik yang dapat diuji untuk membedakan penyebab-penyebab berikut:

• thread API berstatus runnable tetapi menunggu terlalu lama untuk mendapatkan CPU;
• cgroup API di-throttle oleh kuota cpu.max miliknya;
• afinitas atau cpuset membatasi pekerjaan hanya pada beberapa CPU yang sibuk;
• thread API sebenarnya sedang sleep menunggu mutex, I/O, atau event lainnya;
• thread real-time berprioritas lebih tinggi mencegah thread normal untuk berjalan.

Pertanyaan ini cocok untuk peran SRE, infrastruktur, perangkat lunak sistem, performance engineering, dan backend yang membutuhkan pengetahuan runtime Linux. Nilai 16, 6.12, 45ms, 600ms, dan 78% adalah input latihan fiktif, bukan ambang batas kapasitas atau alert yang universal.

Apa yang Sedang Diuji oleh Pewawancara

Batasan pertama adalah task state (status tugas). Scheduler hanya dapat memilih thread yang runnable. Thread yang sedang sleep menunggu mutex, operasi jaringan, operasi disk, atau timer tidak sedang menunggu di run queue CPU. Seluruh interval tersebut tidak boleh dilabeli sebagai keterlambatan penjadwalan. Kandidat harus terlebih dahulu menjawab apakah thread tersebut memang sudah berstatus runnable.

Lapisan kedua adalah model fair-scheduling. Penjelasan CFS terdahulu menggunakan virtual runtime, atau vruntime, untuk mengaproksimasi “CPU multitasking ideal” dan memprioritaskan entitas dengan vruntime yang lebih kecil. Model EEVDF saat ini terus melacak hutang keadilan (fairness debt) yang disebut lag, hanya mengizinkan entitas yang eligible, dan memilih virtual deadline paling awal di antara mereka. Nilai nice atau bobot cgroup mempengaruhi pembagian porsi relatif jangka panjang. Slice permintaan dan virtual deadline mempengaruhi seberapa cepat sebuah task bisa mendapatkan kesempatan eksekusi berikutnya. Tidak ada satu pun dari mekanisme ini yang menjanjikan p99 yang pasti untuk suatu request individu.

Lapisan ketiga adalah hierarki dan batasan lokal. Host dengan kapasitas idle 22% masih dapat memiliki target cgroup yang telah menghabiskan hard quota atau thread yang terkurung pada dua CPU yang jenuh. cpu.weight adalah bobot relatif di antara cgroup turunan (sibling) yang aktif selama terjadi perebutan sumber daya, sedangkan cpu.max memberlakukan batas bandwidth mutlak (hard limit) per periode. Grup tugas dan cpuset dapat membuat nilai agregat host menyembunyikan terjadinya starvation lokal.

Lapisan keempat adalah bukti langsung. Waktu tunggu run-queue dari /proc/12345/schedstat, delay runnable-to-running dari perf sched timehist, serta cgroup cpu.stat dan cpu.pressure lebih dekat dengan mekanisme sebenarnya daripada sekadar CPU agregat atau jumlah context-switch saja. Jawaban yang kuat juga membatasi privilege tracing, overhead, dan durasi.

Terakhir, kandidat membutuhkan batasan mitigasi. Memindahkan API ke SCHED_FIFO dapat membuatnya melakukan preempt terhadap pekerjaan normal, tetapi loop tanpa batas atau pemegang lock kemudian dapat membuat mesin mengalami starvation. Perbaikan harus mengikuti bukti: koreksi kuota yang salah, sesuaikan bobot sibling, perbaiki set CPU, atau investigasi jalur lock atau I/O ketika thread ternyata tidak berstatus runnable.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Di mana pengukuran waktu p99 dimulai dan diakhiri? Pisahkan antrean ingress, eksekusi aplikasi, penantian downstream, dan waktu jaringan klien, lalu sejajarkan sampel host ke interval yang sama.
• Kapan thread target berada dalam status runnable? Dapatkan status thread, alasan off-CPU, atau stack trace. Waktu CPU yang sedikit bisa berarti kurangnya penjadwalan atau kondisi sleep yang berkepanjangan.
• Hierarki cgroup apa yang menaungi API dan job offline? Bandingkan cpu.weight, cpu.max, batas parent, dan cpu.stat untuk keduanya. Parent cgroup juga membatasi child cgroup di bawahnya.
• CPU mana saja yang boleh menjalankan pekerjaan tersebut? Periksa afinitas thread, cpuset.cpus.effective, utilisasi per-CPU, dan tata letak NUMA. Host dengan 16 vCPU tidak berarti thread diizinkan menggunakan seluruh 16 core tersebut.
• Apakah ada entitas penjadwalan real-time? Periksa prioritas dan afinitas CPU untuk tugas SCHED_FIFO dan SCHED_RR. Skenario hanya menyebutkan bahwa thread bisnis yang relevan menggunakan SCHED_OTHER; ini tidak menutup kemungkinan adanya thread real-time lain yang tidak terkait di host.
• Apakah job offline mengubah jalur lock, memori, atau I/O? Kompresi dapat menciptakan perebutan CPU, tetapi juga dapat mengintensifkan reclaim memori, I/O file, atau antrean pada shared worker pool.
• Bisakah trace singkat diambil? perf sched umumnya membutuhkan privilege tambahan dan menimbulkan overhead perekaman. Pastikan indikasinya terlebih dahulu menggunakan counter ber-overhead rendah, lalu lakukan sampling selama 15 detik dalam rentang waktu yang terkendali.

Kerangka Jawaban 30 Detik

“Pertama-tama, saya akan memastikan apakah thread API sudah berstatus runnable selama request yang lambat terjadi. Waktu yang dihabiskan untuk sleep saat menunggu lock atau I/O adalah penantian off-CPU. Keterlambatan penjadwalan adalah interval dari status runnable hingga benar-benar berjalan (running).

Pada Linux 6.12, saya akan menjelaskan fair class melalui EEVDF: ia melacak lag setiap entitas relatif terhadap layanan adil yang ideal, mempertimbangkan entitas yang eligible, dan memilih virtual deadline paling awal. Model smallest-vruntime milik CFS tetap menjadi intuisi historis yang berguna, tetapi tidak sepenuhnya menggambarkan aturan pemilihan saat ini. Nilai nice dan cpu.weight mengubah porsi relatif, cpu.max dapat membatasi secara langsung via throttling, dan afinitas atau cpuset mengontrol CPU mana yang tersedia.

Saya akan memeriksa utilisasi per-CPU, status thread, dan konfigurasi cgroup. Kemudian saya akan membandingkan delta waktu tunggu run-queue di /proc/12345/schedstat, delta throttling di cpu.stat, dan cpu.pressure. Jika bukti masih mengarah ke penjadwalan, saya akan mengambil trace singkat perf sched untuk mengukur delay runnable-to-running secara langsung. Setelah perbaikan diterapkan, saya akan memutar ulang beban yang sama dan memverifikasi p99 API, distribusi scheduling delay, throttling, CPU pressure, serta throughput offline secara bersamaan daripada menyimpulkan penyebab hanya dari utilisasi CPU agregat 78%.”

Analisis Mendalam Langkah demi Langkah

Langkah 1: Tarik Garis Pemisah Antara Runnable dan Sleeping

Ketika CPU membutuhkan tugas lain, scheduler Linux hanya memilih entitas yang runnable pada CPU tersebut atau yang eligible untuk bermigrasi ke sana. Thread dengan kebijakan normal memiliki prioritas penjadwalan 0. Thread real-time SCHED_FIFO dan SCHED_RR menggunakan rentang prioritas statis yang lebih tinggi dan dapat melakukan preempt terhadap thread normal.

Oleh karena itu, sedikitnya waktu CPU pada API memiliki dua penjelasan yang berbeda secara mendasar:

1. Thread berstatus runnable tetapi tidak segera berjalan karena perebutan run-queue, kuota, atau pembatasan CPU set.
2. Thread sleep pada futex, socket, disk, timer, atau antrean aplikasi dan baru menjadi runnable saat event yang ditunggu tiba.

Mulailah dengan memeriksa status thread dan kebijakan penjadwalan:

ps -eLo state,cls,rtprio,pri,ni,psr,pid,tid,comm --sort=-rtprio,-pri
pidstat -t -w -u -p "$pid" 1 10

ps adalah snapshot instan, sehingga satu nilai R atau S saja tidak menyelesaikan masalah. Data context-switch dan CPU dari pidstat membantu mengidentifikasi thread target, tetapi jumlah context-switch yang tinggi tidak membuktikan tingginya scheduling delay. Jika thread lebih banyak sleep, lanjutkan dengan trace aplikasi, pemprofilan lock, stack off-CPU, metrik I/O, dan latensi downstream untuk menemukan kondisi pemicu wake-up.

Langkah 2: Gunakan CFS untuk Intuisi, Lalu Perbarui Model ke EEVDF

Penjelasan CFS klasik menskalakan waktu eksekusi aktual setiap entitas fair berdasarkan bobotnya ke dalam vruntime. Entitas dengan bobot lebih besar mengakumulasi vruntime lebih lambat. Memilih entitas dengan vruntime yang lebih kecil akan mengarahkan alokasi layanan jangka panjang menuju bobot yang telah dikonfigurasi. Ini tetap menjadi intuisi pengajaran yang berguna dan menjelaskan arah bagaimana nice mengubah fair share.

Dokumentasi kernel Linux menyatakan bahwa fair class mulai bertransisi ke EEVDF pada versi 6.6. Jawaban yang ringkas dapat menggunakan dua konsep:

• lag merepresentasikan berapa banyak alokasi layanan yang menjadi hak suatu entitas atau yang telah diterimanya relatif terhadap layanan ideal yang adil; entitas dengan lag >= 0 berstatus eligible;
• di antara entitas yang eligible, scheduler memilih virtual deadline paling awal. Slice permintaan yang lebih pendek menghasilkan deadline yang lebih awal dan meningkatkan peluang respons untuk pekerjaan yang sensitif terhadap latensi.

EEVDF menangani trade-off antara fairness versus latensi, tetapi tidak ada SLA milidetik pasti yang otomatis didapat dari bobot beban. Waktu tunggu sebenarnya tetap bergantung pada CPU yang tersedia, jumlah entitas, hierarki bobot, kuota, waktu wake-up, dan scheduling class yang lebih tinggi. Dalam wawancara, gunakan vruntime CFS untuk intuisi historis, lalu tuntaskan dengan aturan pemilihan EEVDF yang disyaratkan oleh skenario Linux 6.12.

Langkah 3: Pisahkan Nice, Bobot Relatif, Hard Quota, dan CPU Set

Untuk SCHED_OTHER, rentang nice normal adalah -20 hingga 19, dan Linux menyimpan nilai nice per thread. Nilai nice mengubah bobot relatif di dalam fair class. Nilai ini tidak mereservasi CPU dan tidak dapat menghapus batas cgroup. Dengan penjadwalan task-group, entitas di cgroup yang berbeda pertama-tama bersaing di tingkat grup. Mengubah nilai nice (renicing) satu thread di dalam sebuah grup mungkin tidak banyak mengubah pembagian porsi antara dua cgroup.

Tiga kontrol cgroup v2 menjawab pertanyaan yang berbeda:

• cpu.weight bernilai default 100 dan berkisar antara 1 hingga 10000; ini mendistribusikan siklus CPU yang diperebutkan secara proporsional di antara sibling yang aktif;
• cpu.max memiliki format $MAX $PERIOD dan bernilai default max 100000; nilai batas numerik akan me-throttle seluruh cgroup setelah anggaran periodenya habis;
• cpuset.cpus.effective adalah set CPU yang benar-benar tersedia setelah hierarki dan status sistem diterapkan.

Baca batasan pada host, thread, dan target cgroup:

mpstat -P ALL 1 10
taskset -pc "$pid"
cat /sys/fs/cgroup/api/cpuset.cpus.effective
cat /sys/fs/cgroup/api/cpu.weight
cat /sys/fs/cgroup/api/cpu.max
cat /sys/fs/cgroup/api/cpu.stat
cat /sys/fs/cgroup/api/cpu.pressure

Jika nr_throttled dan throttled_usec di cpu.stat meningkat selama interval request yang lambat, cgroup memang telah mencapai batas bandwidth-nya. Anggaran grup yang ketat dapat menghentikan grup tersebut meskipun CPU host lainnya sedang idle; kedua metrik ini memiliki cakupan yang berbeda. Jika counter kuota tetap mendatar tetapi cpuset.cpus.effective hanya bernilai 2-3 sementara CPU 2 dan 3 jenuh, rata-rata host 78% sama menyesatkannya.

Langkah 4: Ukur Waktu Tunggu dari Runnable ke Running secara Langsung

Setelah memilih thread lambat yang representatif, baca scheduling counter-nya dua kali:

cat /proc/"$tid"/schedstat
sleep 5
cat /proc/"$tid"/schedstat

Ketiga kolom tersebut adalah nanodetik kumulatif berjalan pada CPU, nanodetik kumulatif menunggu di run queue, dan jumlah timeslice yang diperoleh. Gunakan delta di antara pembacaan, bukan total kumulatif sepanjang masa aktifnya. Pertumbuhan pesat pada kolom kedua dengan waktu proses (runtime) yang sedikit mendukung kesimpulan "runnable tetapi tidak segera berjalan", meskipun kuota, afinitas, dan thread berprioritas lebih tinggi tetap perlu diperiksa untuk menjelaskan penyebabnya.

Ketika distribusi dan linimasa diperlukan, ambil trace singkat di seluruh sistem:

sudo perf sched record -a -- sleep 15
sudo perf sched timehist --state --summary

perf sched timehist dapat menunjukkan waktu tunggu, delay penjadwalan dari runnable hingga running, dan runtime, sembari memetakan wake-up, migrasi, dan CPU ke dalam linimasa. Di lingkungan produksi, pastikan terlebih dahulu dukungan kernel, privilege, ruang disk, dan overhead yang dapat diterima. Batasi jendela pengumpulan data dan hapus data trace yang tidak lagi diperlukan. Satu sampel 15 detik yang melewatkan event di ekor distribusi (tail event) tidak serta-merta membebaskan scheduler dari masalah; bandingkan distribusi pada pengujian sebelum dan sesudah yang dapat direproduksi.

Langkah 5: Kerucutkan Menjadi Lima Penyebab dengan Bukti yang Membedakan

Gunakan matriks berikut untuk mempersempit penyebabnya:

cpu.pressure mengukur waktu di mana pekerjaan yang runnable tidak dapat membuat progres karena perebutan CPU. Ini adalah bukti yang berguna bahwa persaingan CPU mempengaruhi beban kerja, tetapi metrik ini tidak membedakan antara bobot relatif yang tidak memadai, throttling kuota, atau pinning yang buruk. cpu.stat, afinitas, dan trace scheduler melengkapi pembedaan tersebut.

Pekerjaan real-time mengikuti jalur prioritas yang terpisah. Thread SCHED_FIFO berjalan hingga ia terblokir, di-preempt oleh thread real-time berprioritas lebih tinggi, atau secara sukarela menyerahkan giliran (yield). SCHED_RR hanya menambahkan quantum di antara thread dengan prioritas real-time yang sama. Tidak ada bobot fair-class yang dapat membuat thread normal mengungguli thread real-time berprioritas lebih tinggi yang terus-menerus runnable.

Langkah 6: Perbaiki Mekanisme yang Terbukti dan Verifikasi Metrik Bisnis serta Scheduler

Setiap mitigasi harus sesuai dengan mekanisme yang telah dikonfirmasi:

• kuota buruk: naikkan atau hapus cpu.max yang salah setelah mengevaluasi kapasitas dan dampaknya terhadap beban kerja tetangga;
• porsi relatif tidak memadai: naikkan bobot cgroup API, kurangi bobot cgroup offline, atau turunkan prioritas nice dari task offline;
• set CPU buruk: perluas atau seimbangkan kembali cpuset atau afinitas sambil memeriksa lokalitas NUMA dan cache;
• perebutan fair-class: batasi konkurensi offline, bagi batch menjadi lebih kecil, atau gunakan SCHED_BATCH atau SCHED_IDLE untuk pekerjaan offline yang sesuai;
• penantian sleep: perbaiki perebutan lock, worker pool, I/O, memory pressure, atau layanan downstream; penyesuaian scheduler biasanya tidak memberikan manfaat;
• starvation real-time: hapus kebijakan real-time yang tidak perlu, batasi runtime, dan periksa priority inversion serta ketergantungan lock.

Jalankan perbandingan sebelum dan sesudah pada tingkat request dan beban offline yang sama. Verifikasi setidaknya p50/p95/p99 dan error pada API, distribusi delay penjadwalan per-thread, delta waktu tunggu run-queue schedstat, throttling cgroup, CPU pressure, utilisasi per-CPU, dan throughput offline. Peningkatan p99 API tidak boleh memicu starvation permanen pada job offline atau memindahkan beban ke layanan downstream maupun tenant lain.

Contoh Jawaban yang Kuat

“Rata-rata CPU host sebesar 78% tidak membebaskan scheduler dari masalah. Linux menjadwalkan thread, dan batasan dapat berada di tingkat thread, CPU, atau cgroup. Pertama-tama, saya akan memastikan apakah thread yang menangani request lambat berstatus runnable. Jika ia sleep pada futex atau I/O, waktu CPU-nya yang rendah terutama mencerminkan penantian sinyal wake-up, sehingga scheduler memang tidak dapat memilihnya.

Skenario menentukan Linux 6.12. vruntime pada CFS menjelaskan intuisi keadilannya, tetapi proses pemilihan saat ini harus dijelaskan dengan EEVDF: scheduler melacak lag relatif terhadap layanan ideal, membiarkan entitas dengan lag >= 0 bersaing, dan memilih virtual deadline paling awal. Nilai nice dan cpu.weight mengubah porsi relatif jangka panjang; cpu.max menetapkan batas atas periodik yang ketat; afinitas dan cpuset membatasi CPU mana yang eligible. Tak satu pun dari mekanisme tersebut yang secara otomatis menjamin p99 sebesar 45ms.

Saya akan menjalankan mpstat -P ALL, lalu membaca cpuset.cpus.effective, cpu.weight, cpu.max, cpu.stat, dan cpu.pressure untuk cgroup API. Jika nr_throttled dan throttled_usec meningkat sepanjang interval lambat tersebut, maka kuota throttling teramati secara langsung; kapasitas host yang idle tidak mengubah kesimpulan ini. Jika pekerjaan terkurung pada CPU 2 dan 3 dan kedua CPU tersebut penuh, saya akan memperbaiki set CPU lokal terlebih dahulu.

Jika tidak ditemukan anomali throttling maupun pinning, saya akan mengambil dua pembacaan /proc/12345/schedstat untuk TID yang representatif dan menghitung delta waktu tunggu run-queue. Di bawah beban yang dapat direproduksi, saya akan mengambil trace singkat perf sched record dan memeriksa timehist untuk melihat delay runnable-to-running, pihak yang melakukan wake-up (waker), dan CPU-nya. Waktu tunggu run-queue yang rendah dikombinasikan dengan kondisi sleep yang lama akan mengalihkan penyelidikan ke lock, I/O, antrean aplikasi, dan trace downstream.

Misalkan bukti menunjukkan cgroup API dikonfigurasi sebagai 20000 100000, dengan throttling yang meningkat selaras dengan p99. Saya akan memperbaiki anggaran kuota menggunakan kapasitas terukur dan membatasi konkurensi offline. Saya tidak akan serta-merta memindahkan API ke SCHED_FIFO. Pengujian ulang akan menggunakan traffic dan batch job yang sama, dan mensyaratkan p99 API, delay penjadwalan, throttling, dan CPU pressure untuk turun bersamaan sementara throughput offline tetap dapat diterima dan tidak ada task yang mengalami starvation.”

Kesalahan Umum

• Menganggap 78% CPU host sebagai bukti tidak ada masalah CPU → nilai rata-rata menyembunyikan kuota cgroup dan set CPU lokal → periksa tampilan per-CPU, cgroup, dan thread secara bersamaan.
• Menyebut semua waktu off-CPU sebagai delay penjadwalan → thread yang sedang sleep belum berstatus runnable → gunakan status, stack, dan trace untuk menetapkan titik wake-up terlebih dahulu.
• Hanya menghafal “CFS memilih vruntime terkecil” → fair class mulai bertransisi ke EEVDF pada Linux 6.6 → jelaskan eligible lag dan virtual deadline paling awal.
• Mengasumsikan cpu.weight=200 mereservasi dua CPU → bobot mengekspresikan porsi relatif di antara sibling aktif di bawah perebutan sumber daya → desain kapasitas secara terpisah dan gunakan cpu.max untuk batas atas yang ketat.
• Mengasumsikan nice secara langsung mengurutkan semua kontainer → task group pertama-tama bersaing di tingkat hierarki cgroup → periksa bobot grup sebelum memutuskan apakah perlu mengubah nice pada thread.
• Menyimpulkan latensi scheduler hanya dari banyaknya context switch → I/O normal dan konkurensi juga dapat menciptakan context switch → ukur waktu tunggu run-queue schedstat dan delay perf sched.
• Menggunakan SCHED_FIFO sebagai perbaikan instan untuk API → thread real-time berprioritas tinggi dapat memicu starvation pada pekerjaan normal dan memperbesar risiko lock → pertimbangkan kebijakan real-time hanya untuk deadline riil, runtime yang terikat, dan analisis keamanan yang lengkap.
• Menaikkan bobot API tanpa memeriksa kuota → cgroup akan tetap terkena throttle setelah mencapai cpu.max → buktikan adanya throttling dengan cpu.stat dan perbaiki batasannya.
• Hanya memeriksa p99 API → perubahan konfigurasi dapat menyebabkan starvation pada batch job atau menurunkan performa tenant lain → verifikasi fairness, throughput, pressure, dan error juga.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan Lanjutan 1: Mengapa cgroup Dapat Terkena Throttle Sementara Host Masih Memiliki CPU yang Idle?

cpu.max membatasi bandwidth CPU yang dikonsumsi oleh cgroup tersebut selama satu periode. Setelah anggarannya habis, grup akan menunggu periode berikutnya meskipun CPU yang tidak digunakan oleh grup lain sedang idle. Periksa cpu.max dan bandingkan delta pada nr_throttled dan throttled_usec dari cpu.stat pada interval yang sama. Nilai-nilai tersebut menjawab apakah hard limit terpicu secara lebih langsung daripada utilisasi host agregat.

Pertanyaan Lanjutan 2: Mengapa Mengubah Nilai Nice (Renicing) Thread API Mungkin Tidak Banyak Berpengaruh?

Linux menerapkan nilai nice per thread, tetapi dengan group scheduling, cgroup yang berbeda pertama-tama bersaing sebagai entitas penjadwalan menggunakan bobot grup. Renicing terutama hanya mengubah porsi thread di dalam grupnya sendiri. Hal ini tidak dapat menghapus cpu.max parent, dan mungkin tidak mengubah rasio antara grup API dan grup offline. Petakan hierarki cgroup dan bobotnya sebelum memilih antara nice pada thread atau cpu.weight pada grup.

Pertanyaan Lanjutan 3: Apakah Memindahkan API ke SCHED_FIFO Akan Memperbaiki p99?

Hal ini mungkin memperpendek waktu tunggu thread target, tetapi menimbulkan risiko yang jauh lebih besar. Thread FIFO yang terus-menerus runnable dapat menekan seluruh pekerjaan normal di fair-class. Jika ia melakukan spinning, memegang lock, atau bergantung pada thread normal yang dibuatnya mengalami starvation, sistem dapat berhenti membuat progres. Evaluasi kebijakan real-time hanya jika pekerjaan memiliki batas waktu (deadline) yang nyata, runtime dibatasi secara ketat, priority inversion ditangani, dan proteksi fallback tersedia.

Pertanyaan Lanjutan 4: Apakah EEVDF Menjamin Layanan CPU dalam Satu Slice?

Tidak. Virtual deadline mengurutkan entitas penjadwalan yang eligible, dan slice mengekspresikan preferensi latensi. CPU yang tersedia, jumlah entitas, bobot, kuota, afinitas, dan scheduling class yang lebih tinggi tetap mempengaruhi waktu tunggu nyata. EEVDF menyediakan mekanisme scheduler untuk menyeimbangkan keadilan dan latensi; ini bukanlah SLA p99 tingkat bisnis.

Pertanyaan Lanjutan 5: Bagaimana Cara Memisahkan Waktu Tunggu Mutex dari Waktu Tunggu Run-Queue?

Thread yang menunggu mutex biasanya berada dalam kondisi sleep dan baru menjadi runnable setelah lock dilepaskan. Waktu tunggu run-queue dimulai setelah thread berstatus runnable. Sejajarkan stack off-CPU aplikasi atau eBPF serta metrik futex/lock dengan /proc/12345/schedstat dan perf sched timehist. Sleep futex yang dominan dengan waktu tunggu run-queue yang rendah mengindikasikan masalah lock; delay runnable-to-running yang dominan mengindikasikan masalah penjadwalan atau kontrol sumber daya.

Pertanyaan Lanjutan 6: Kapan Pinning CPU Benar-benar Dapat Membantu?

Isolasi yang dirancang dengan baik dapat mengurangi migrasi, gangguan cache, dan interferensi dari noisy neighbors, misalnya dengan mereservasi CPU yang kapasitasnya telah teruji khusus untuk thread yang sensitif terhadap latensi. Set CPU harus cukup besar, interrupt dan background work perlu dikelola, serta antrean per-CPU memerlukan pemantauan. Pinning yang buruk justru menciptakan kongesti lokal saat kapasitas host masih idle, jadi selalu verifikasi hasilnya dengan utilisasi per-CPU dan scheduling delay.