Effizienz von /proc und /sys & mögliche Alternative

06/04/2012 - 05:30 von Hauke Laging | Report spam
Moin,

abseitige Gedanken zu nàchtlicher Stunde... :-)

Mir geht gerade durch den Kopf, dass das Konzept von /proc und /sys, auf
quasi alles als Datei zugreifen zu können, natürlich cool ist, aber für eine
Gesamtübersicht so richtig schön ineffizient. Und wie ich jetzt gerade sehe,
betrifft dasselbe Problem auch das Einlesen von Dateidaten ganzer
Verzeichnisbàume im normalen Dateisystem.

Ich habe hier (zugegebenermaßen nur ein E-450) gerade mal lsof -n laufen
lassen. Das hat (Ergebnis in tmpfs geschrieben!) über vier Sekunden
gedauert. Die Ausgabe ist knapp 90.000 Zeilen lang. strace (das hat richtig
lange gedauert...) enthüllt fast 300.000 Kernelaufrufe.

lsof ist natürlich ein extremes Beispiel. Ich denke eher an Tools, die so
nebenher laufen (top ist da sicherlich ein harmloser Fall). Gerade wenn mit
feiner zeitlicher Granularitàt Daten erfasst werden sollen, wird da IMHO
viel Rechenleistung durch die Prozesskontextwechsel verplempert.

Mir kam gerade der Gedanke, dass dies dramatisch abgekürzt werden könnte:
Ein Prozess, der den ganzen Inhalt von /proc oder jedenfalls viel davon
braucht, könnte statt mehrerer hunderttausend einen einzigen Aufruf tàtigen.
Eine Anfrage an den Kernel, in der steht, was benötigt wird. Also z.B.,
welche Dateien aus dem Verzeichnis jedes Prozesses. Der Kernel erzeugt dann
eine große XML-"Datei", in der das alles steht, und schiebt die in richtig
großen Blöcken an den aufrufenden Prozess. Um den Faktor 1.000 weniger
(Userspace-Kernelspace-)Aufwand.

Ganz àhnlich könnte man das für normale Dateisysteme machen. Man wàre damit
sogar ein Stück weit unabhàngig vom Kernel-API.

Das einzige, was mir gerade als Gegenargument einfàllt, ist die Komplexitàt:
Derart komplexe Abfragen (Liste der gewünschten Dateien) hat der Kernel
sonst nicht zu bearbeiten. Aber auch die könnte man ja begrenzen, indem man
z.B. festlegt, dass nur eine bestimmte Menge an Daten gleichzeitig abgerufen
werden kann. Ggf. werden dann eben mehrere Abfragen fàllig, was aber
kernelseitig keine messbaren Performanceeinbußen haben dürfte.


CU

Hauke
 

Lesen sie die antworten

#1 Edzard Egberts
06/04/2012 - 08:05 | Warnen spam
Hauke Laging schrieb:

viel Rechenleistung durch die Prozesskontextwechsel verplempert.

Mir kam gerade der Gedanke, dass dies dramatisch abgekürzt werden könnte:
Ein Prozess, der den ganzen Inhalt von /proc oder jedenfalls viel davon
braucht, könnte statt mehrerer hunderttausend einen einzigen Aufruf tàtigen.



Was hat das mit den Kontextwechseln zu tun? Ist es denn ein Unterschied,
wenn ein Prozess mehrfach den Kernel aufruft, im Gegensatz dazu, dass
der Kernel diese Routinen selber aufruft? Die Menge abgearbeiteter
Codezeilen sollte doch etwa gleich bleiben, nur die Schnittstelle
verlagert sich.

Das einzige, was mir gerade als Gegenargument einfàllt, ist die Komplexitàt:



Ich frage mich eher, ob so etwas hàufig genug gebraucht wird.

Ähnliche fragen