[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index


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

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



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").
>  |
>  |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?
[...]
>  |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
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 ...

        hp

-- 
   _  | Peter J. Holzer     | You can do reverse engineering,
|_|_) | Schriftführer LUGA  | but you can't do reverse hacking.
| |   | hjp@luga.at         |
__/   | http://www.luga.at/ | -- Vilayanur S. Ramachandran

Attachment: signature.asc
Description: Digital signature



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