EEVDF sub lupă: cum urmărești wakeup-urile, virtual deadlines și latența reală a proceselor în schedulerul Linux

EEVDF — Earliest Eligible Virtual Deadline First — schimbă modul în care Linux decide ce proces normal primește CPU-ul următor. Kernelul a început tranziția de la modelul CFS către EEVDF în Linux 6.6, păstrând ideea de fairness bazată pe virtual runtime, dar introducând explicit noțiunile de lag, eligibility și virtual deadline.

Pentru diagnosticare, nu este suficient să privești top. Trebuie să corelezi momentul în care task-ul devine runnable, cât așteaptă până primește CPU și valorile EEVDF pe care schedulerul le folosește intern.

Nu confunda virtual deadline cu SCHED_DEADLINE

În EEVDF, un task are lag pozitiv dacă schedulerul îi „datorează” CPU și lag negativ dacă a primit deja mai mult decât partea sa. Sunt eligibile task-urile cu lag cel puțin zero, iar dintre acestea este preferat cel cu cel mai timpuriu virtual deadline.

Acest virtual deadline nu este un termen real exprimat în timpul de perete și nu garantează finalizarea aplicației până la o anumită oră. Nu trebuie confundat cu politica real-time SCHED_DEADLINE, care utilizează parametrii runtime, period și deadline și aplică un model EDF/CBS separat.

Găsește procesul și verifică schedulerul

Presupunem că aplicația analizată este myapp:

PID="$(pgrep -n myapp)"
echo "$PID"

ps -o pid,tid,psr,ni,pri,stat,comm -p "$PID"
chrt -p "$PID"

Păstrează PID-ul; îl vom folosi în toate măsurătorile.

Vezi direct vruntime, eligibility și virtual deadline

Kernelurile recente expun informații detaliate despre runqueue prin debugfs. Dacă debugfs nu este deja montat:

sudo mount -t debugfs none /sys/kernel/debug

Inspectează headerul:

sudo grep -A3 'runnable tasks' \
  /sys/kernel/debug/sched/debug | head

În kernelul upstream actual apar coloane precum:

PID
vruntime
eligible
deadline
slice
sum-exec
switches
prio
wait-time

Caută procesul:

sudo grep -E \
"(^|[[:space:]])${PID}([[:space:]]|$)" \
/sys/kernel/debug/sched/debug

Poți observa evoluția:

watch -n 0.5 \
"sudo grep -E '(^|[[:space:]])${PID}([[:space:]]|$)' \
/sys/kernel/debug/sched/debug"

În implementarea actuală, scheduler debug afișează explicit se.vruntime, dacă entitatea este eligibilă, se.deadline și slice-ul. Acesta este însă un debug interface, nu un ABI stabil; coloanele se pot schimba între versiuni de kernel.

Urmărește wakeup-urile și momentul când task-ul primește CPU

Pentru o captură practică:

sudo perf sched record -- sleep 15

În cele 15 secunde reproduce workload-ul. Apoi:

sudo perf sched timehist \
  --pid "$PID" \
  --wakeups

perf sched timehist separă trei valori extrem de utile:

wait time
sch delay
run time

sch delay reprezintă timpul dintre momentul în care task-ul este runnable și momentul în care chiar începe să execute pe CPU. Opțiunea --wakeups include și evenimentele de wakeup.

Pentru statistici agregate:

sudo perf sched latency -p

Raportul arată runtime, numărul întârzierilor, latența medie și latența maximă per PID.

Verifică tracepoint-urile direct

Kernelul expune evenimentele schedulerului prin tracing:

grep 'sched_wak' \
  /sys/kernel/tracing/available_events

cat /sys/kernel/tracing/events/sched/sched_wakeup/format

Pentru detalii brute poți înregistra:

sudo perf record \
  -e sched:sched_wakeup \
  -e sched:sched_switch \
  -a -- sleep 10

sudo perf script

sched_wakeup arată când task-ul este făcut runnable, iar sched_switch când CPU-ul trece efectiv la alt task. Infrastructura trace events permite inclusiv filtre bazate pe câmpurile descrise în fișierul format.

Confirmă latența acumulată cu schedstat

Pentru procesul analizat:

cat "/proc/${PID}/schedstat"

Cele trei câmpuri sunt:

timp executat pe CPU
timp total așteptat în runqueue
număr de timeslice-uri

Toate timpurile sunt exprimate în nanosecunde. Astfel poți compara două intervale și vedea dacă procesul acumulează rapid runqueue wait chiar dacă utilizarea CPU pare normală.

Un diagnostic EEVDF serios corelează aceste perspective: wakeup → eligibility și virtual deadline → scheduler delay → rularea efectivă. Dacă sched_wakeup apare imediat, dar sch delay crește, problema nu este trezirea procesului, ci competiția pentru CPU sau decizia schedulerului. Dacă virtual deadline-ul și eligibility se schimbă, acestea trebuie interpretate împreună cu nice level, slice, workload și celelalte task-uri de pe runqueue — nu izolat.

Surse folosite

Linux Kernel Documentation — EEVDF Scheduler și mecanismele lag, eligibility și virtual deadline.

Linux Kernel source — kernel/sched/debug.c, câmpurile EEVDF expuse prin scheduler debug.

Linux Kernel Documentation — scheduler trace events și sched_wakeup.

Linux Kernel Documentation — /proc/<pid>/schedstat și runqueue waiting time.

Linux perf documentation — perf sched latency, timehist și analiza wakeup-urilor.