Timm M. Steinbeck und Arne Wiebalck Lehrstuhl für Technische Informatik Universität Heidelberg. Prozess-Monitoring auf CPU-Takt Ebene

Transkript

1 Timm M. Steinbeck und Arne Wiebalck Lehrstuhl für Technische Informatik Universität Heidelberg Prozess-Monitoring auf CPU-Takt Ebene

2 Einleitung Unser Arbeitsgebiet: ALICE Teilchenphysik Experiment Cluster im Auslesesystems, PCs Eingangsdatenrate 25 GB/s Viel Datenanalyse/Berechnungen Viel Netzverkehr Anzahl Rechner/Kosten möglichst klein Wünschenswert: Wenig CPU Last durch Netzwerkverkehr (% CPU Last / MB/s) Ein Projekt: Entwicklung eines Low-Overhead Netzwerkprotokolls Benutzung des Standard Kernel Netzwerk-Device Interfaces Eigenes Kernel-Modul

3 Last-Messungen Ergebnisse nicht wirklich realistisch: Extrem konstanter Netzwerkdurchsatz Aber unregelmäßige CPU Last auf SMP-System Auf UP-System kaum messbare Last Woher kommen diese Werte??

4 Analyse der Messung Woher kommen diese Werte?? Datenquelle f. Monitoring Programme (top, xosview,...): /proc/stat Daten werden gefüllt von Kernel-Funktion update_process_times() (kernel/timer.c) Aufruf am Ende jeder Zeitscheibe (system ticks / jiffies) Zeitscheibendauer: 10 ms (Kernel 2.4) Prozeß aktiv (nicht Idle-Task): - Zähler f. benutzte Zeitscheiben wird inkrementiert - Zeitscheibe wird Prozeß zugerechnet Verdacht: Granularität der Abrechnung führt zu unrealistischen Meßwerten

5 Einschub: Scheduler Scheduler teilt den Prozessen CPU-Zeit zu Granularität der Zuweisung sind Zeitscheiben von 10 ms Scheduling-Algorithmus entscheidet über nächsten Prozess Prozesse können die CPU vor Ende ihrer Zeitscheibe abgeben Der Scheduler wählt dann einen anderen Prozess aus Scheduler und update_process_times()werden dennoch bei jedem System-Tick ausgeführt Zeit Prozess A Idle Prozess B Prozess B Prozess A Zeitscheibe 10 ms Scheduler und update_process_times()

6 Die Ursache Prozess gibt CPU vorzeitig ab! Zeit Idle Prozess Prozess Zeitscheibe 10 ms Scheduler und update_process_times()

7 Harvey #include <unistd.h> #include <sys/time.h> #define RUNTIME 9000 int main( int argc, char** argv ) { unsigned long n=0; unsigned long t; struct timeval s, e; while ( 1 ) { gettimeofday( &s, NULL ); do { n++; gettimeofday( &e, NULL ); t = (e.tv_sec-s.tv_sec)* (e.tv_usec-s.tv_usec); while ( t < RUNTIME ); usleep( 0 ); Harvey rechnet definierte Zeit lang (RUNTIME) Schläft anschliessend für den Rest der Zeitscheibe (usleep) Dies wird in Endschlosschleife wiederholt

8 CPUMeter #include <stdio.h> #include <sys/time.h> #include <unistd.h> int main( int argc, char** argv ) { unsigned long long cur; #define TIME unsigned long long get_iterations( unsigned long t_musec ) { unsigned long long n = 0; struct timeval s, e; unsigned long tdiff; gettimeofday( &s, NULL ); while ( 1 ) { n++; gettimeofday( &e, NULL ); tdiff = (e.tv_sec-s.tv_sec) * (e.tv_usec-s.tv_usec); if ( tdiff >= t_musec ) break; return n; while ( 1 ) { cur = get_iterations( TIME ); printf( "%20Lu iter./s\n", cur ); return 0; Misst Iterationen pro Sekunde Maß für verfügbare CPU-Zyklen

9 Abhilfe: Kernel-Patch Precise Accounting Patch Problem bereits früher aufgetreten: Patch von Jan Astalos für / Patch zählt verbrauchte Takt-Zyklen mit Hilfe des Time Stamp Counters der CPU Abrechnung erfolgt nach Kontext-Wechsel (und nicht nur nach Ablauf einer Zeitscheibe) Patch von Jan bildete Grundlage für eigenen Patch Anpassung an aktuelle Kernel-Versionen (seit ) Zusätzliche Erweiterungen: - Abrechnung global und pro CPU - Berücksichtigung von Interrupts und Soft-IRQs

10 Die Zentrale Funktion void update_process_cycles(void) { struct task_struct *p = current; int cpu = smp_processor_id(); cycles_t t = get_cycles(); p->cycles[cpu] += t - last_cycles[cpu]; if ( p->pid ) kstat.used_cycles[cpu] += t - last_cycles[cpu]; last_cycles[cpu] = t; Wird bei jedem Prozess-Wechsel aufgerufen Aktualisiert verbrauchte Zyklen - Pro Prozess - Pro CPU

11 Harvey enttarnt

12 Der Preis Auswirkungen Zusätzliche Anweisungen erhöhen Dauer eines Kontext-Wechsels 10% - Effekt Messung mittels LMbench (

13 Fazit Standard Schnittstelle des Kernels kann irreführende Werte liefern nur bei bestimmtem Programm-Verhalten in der Regel sind Werte realistisch unsichtbare Prozesse möglich Vorgestellter Patch kann Problem lösen Genauere Abrechnung erkauft mit erhöhter Latenz beim Kontext-Wechsel Problem besteht auch in Kernel 2.6, wir arbeiten dran... Patch verfügbar unter: