[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:
 |On 2016-10-06 16:48:50 +0200, Steffen Nurpmeso wrote:
 |> "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").
  ...
 |>|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?
 |
 |Nein, ich meine dass die Zuordnung des "IO-wait"-States zu einem Core
 |willkürlich ist. "Es gibt mindestens einen Prozess, der auf I/O wartet"
 |ist ein globaler Zustand des ganzen Systems, nicht eines einzelnen
 |Cores. Wenn die I/O-Operation irgendwann beendet ist, wird der Prozess
 |neu geschedult werden, und dann wird er auf einem Core laufen, der dann
 |gerade frei ist. Aber dieser Core wartet *jetzt nicht* auf I/O. Er

Ich wäre mir hier nicht so sicher.  Wieso "*jetzt nicht*"?  Es
gibt auch _explizit_ synchrone Systemaufrufe, ich denke da an
fcntl(F_FULLSYNC) von Mac OS X (Snow Leopard).  Es ist zwar
denkbar und vielleicht sogar wahrscheinlich, daß ein hervorragend
ausprogrammierter Kernel in der Lage ist, eine solche Aufgabe auch
zu parallelisieren, siehe Kernellast im Ext3/Ext4 Faden, aber es
gibt nur ein initiierendes Programm, und deswegen denke ich, daß
es seine Statistiken sind, die hier belastet werden.  Das müßte
dann gar für "wa" in 100*Prozessormenge Prozessorlast münden.

 |wartet darauf, dass irgendein Prozess auf ihm geschedult wird - aus
 |welchem Grund auch immer. Und natürlich kann der Kernel nicht in die
 |Zukunft sehen, weiß also noch nicht, wo er einen gegebenen wartenden
 |Prozess dann schlussendlich scheduln wird.
 |
 |Praktisch fallen mir zwei Möglichkeiten ein:
 |
 |1) auf I/O wartende Prozesse werden gleichmäßig über die freien Cores
 |   verteilt.  Wenn ein Prozess auf einem 8-Core-System  wartet, bekommt
 |   entweder ein zufälliger Core den "wa"-State zugeteilt, oder jeder
 |   0.125 wa-States.
 |2) Ein auf I/O wartender Prozess bleibt dem Core zugeteilt, auf dem er
 |   gelaufen ist, als er den entsprechenden I/O-Request abgesetzt hat.
 |
 |Ersteres ist eine rein verrechnungstechnische Maßnahme, zweiteres macht
 |vom Schedulung her Sinn (wenn der I/O-Request rasch fertig ist, sollte
 |der Prozess am gleichen Core weiterlaufen, damit diverse Caches genutzt
 |werden können). Aber beides führt zu Anomalien: Im ersten Fall wächst
 |der I/O-Wait-State linear mit der Anzahl der wartenden Prozesse bis zur
 |Anzahl der Cores und bleibt dann gleich. Im zweiten hängt es zufällig
 |davon ab, auf welchen Cores die Prozesse gelaufen sind ...

Ehrlich gesagt kann ich mir alles andere als 2) gar nicht
vorstellen.  Aber das wirklich Schlimme ist ja, daß man mit
zunehmendem Alter bequemer wird, und ich seit zehn Minuten
schreibe und noch nicht versucht habe, eine tatsächliche Antwort
auf deine Frage zu finden!  Skandal!  Und: wofür gibt es denn
eigentlich Studenten?
Gute Nacht.

--steffen



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