[LUGA] Mit freundlicher Unterstützung von:
init.at

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [luga] Was bedeutet IO-wait auf einem Mehrprozessorsystem?



"Peter J. Holzer" <hjp-luga2@hjp.at> wrote:
 |Top zeigt an, wieviel Zeit jeder Core in diveresen Zuständen verbringt,
 |User-Zeit, System-Zeit, Interrupts, ... und auch IO-wait ("wa").
 |
 |Bei einem Single-Prozessor-System ist mir das klar: Wenn der Prozessor
 |nichts zu tun hat, aber es mindestens einen Prozess gibt, der auf I/O
 |wartet, dann wird das hier gezählt.
 |
 |Aber was bedeutet das bei einem System mit mehreren Cores? Wenn ich 8
 |Cores habe, die alle nichts zu tun haben, und einen Prozess, der auf I/O
 |wartet, dann kann man wohl kaum sagen, dass 8 Cores im Zustand IO-wait
 |sind. Andererseits läuft der Prozess, der da auch I/O wartet, derzeit
 |auf allen Cores nicht, also wäre es eher unsinnig, zu sagen, dass ein
 |Core im Zustand I/O-wait ist und alle anderen idle. Vor allem: Welcher?
 |Und was ist, wenn mehrere Prozesse auf I/O warten?

Vielleicht wird das obsolet, je raffinierter umgesetzt die
Treiberprogrammierung ist.  Aber ich weiß noch unter FreeBSD
4.7 bis 5.3, das burncd(1)-Programm; hat direct mit ioctl()
gearbeitet, denke ich, und mußte -- an Ort und Stelle -- warten,
bis der ATA-Befehl, oder was, abgearbeitet war.  Ein
nicht-unterbrechbarer (uninterruptible) sleep.  Dies könnte hier
gezählt werden, die Zeit, die ein Hardwaretreiber o. Ä. nicht
unterbrechbar, auch durch andere Hardware-Interrupts, wartet.

 |Irgendwie scheint mir jede mögliche Lösung reichlich willkürlich zu
 |sein. Was macht der Linux-Kernel hier wirklich?

Interessante Frage.  Du meinst mit "Poll"-Listen, die periodisch
abgefragt werden, und die dann wiederum "Soft-Interrupts"
auslösen, deren Handler dann die "hart" schlafenden Prozesse
weiterführen oder aufwecken, kann das komplett umgangen werden?
Ich habe keinerlei Ahnung von Hardware: vielleicht unterstützt
neue Hardware "Komplettierungs-Quittierungs-Interrupts" o. Ä.,
also komplett asynchrone Steuerung?  Dies wäre meine Idee.  Aber
ältere Hardware und/oder Protokolle werden ja auch noch
unterstützt...  Und ich bin ja absolut überzeugter Anhänger von
Objektorientierter, Ereignisgesteuerter Software, ehrlich.
(Meine Realität sieht im Moment aber auch anders aus...)

--steffen



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
Oktober 2016