[Eisfair] Eisfair Starup Waits und VM

[Hilmar Böhm]

Hallo Marcus,

vielen Dank für Deine späte Nachricht.

Ich habe mir die E64-VM mal von dem langsamen "Server/Host" auf eine schnelleres System kopiert, um da mal die fraglichen 
Phänomene zu testen.

Zu den beiden Systemen:

das Langsamere ist das Ältere:
Zotac (2010), CPU: Pentium U2300 / 2 Kerne / 1.2 GHZ, aktuelle 500G SATAII-SSD, wird aber wahrscheinlich als 3G-SATA SSD 
genutzt(HW-bedingt) / 8GB Mem./ OS: akt. Arch Linux (orig., kein Derivat, keine GUI), Virtualisierung: QEMU 3.1.0-2 + Libvirt 
5.1.0-1 (KVM)

TUXEDO (2016), ASRock Z170M-ITX/ac, CPU: i7-6700 4/8, max 4GHz, SSD-Drives (Samsung_SSD_850) / 32GB Mem, /OS: Debian 9 (GUI: 
KDE), Virtualisierung: QEMU-KVM 2.8, Libvirt 3.0.0/stable, virt-manager 1.4.0-5

Die E64-VM: 2vCPU's, 2G Mem, 10G vHD virtio-scsi-Anbindung.

Die gleiche e64-VM braucht auf dem Zotac-System zum Booten:  69s
Die gleiche e64-VM braucht auf dem TUXEDO/Debian System:     19s
    (beide Systeme original, also ungehackt)

Das gesamte S03udev Init-Script (inkl. Settle) braucht auf dem Debian-System:  <= 1s ! also keine Verzögerung

Wenn ich das "sleep 10" ("Waiting for SCSI/SATA/PATA devices...")
im initramfs/init ausknipse, braucht der ganze Bootvorgang:         _9s_!!
Das ist schon ganz ordentlich!

Ich vermute, dass auf dem schnelleren System die Event-Queue beim "udevadm settle" klein oder gar nicht existent ist.
Auf dem langsameren System wirkt sich vermutlich der schwache Prozessor, der langsamere Speiche und die langsamere SSD-Anbindung 
aus. Es könnten natürlich auch andere HW-bedingte Gründe geben, ich nicht kenne und bisher auch noch nicht in Betracht gezogen habe.

Damit ist wahrscheinlich die Sache gestorben... ? :-(
(Wenn es nicht noch eine Idee gibt.)

Grüße. / Hilmar.




Am 06.03.19 um 23:15 schrieb Marcus Roeckrath:
> Hallo Hilmar,
> 
> Hilmar Böhm wrote:
> 
>> Ergebnisse:
>>
>> Wed Mar 5 09:43.31 CET 2919 Getartet udev daemon
>>
>> Wed Mar 6 09:43.31 CET 2919 Trigger subsystems add
>> Wed Mar 6 09:43.31 CET 2919 Trigger devices add
>> Wed Mar 6 09:43.31 CET 2919 Trigger devices change
>> Wed Mar 6 09:43.33 CET 2919 Trigger devices change
>> Wed Mar 6 09:43.35 CET 2919 End Trigger
>>
>> Wed Mar 5 09:43.36 CET 2919 Start Settle
>> Wed Mar 5 09:43.58 CET 2919 End Settle        <--- 22s
>>
>> -------------------------------------------------------
>>
>>   > ...und zwar nur die Echos aus dem udev-Initskript.
>> Das würde Dir so passen :-)
>> Ich habe noch ein paar Anmerkungen:
> 
> Das wollte ich auch nicht ausschliessen; nur andere Teile vom Bootbildschirm
> waren jetzt nicht mehr nötig.
> 
>> Der Übeltäter ist das "udevadm settle".
> 
> Hatte auch genau das in Verdacht.
> 
>> Settle bedeutet meist <wait> bzw.
>> timeouts. Frage ist, ob das in einer VM auch erforderlich ist.
> 
> Auf echter Hardware scheint das ja viel schneller zum Ende zu kommen, denn
> prinzipiell ist es ja schon sinnvoll, dass auf die vorher getriggerten
> Events gewartet wird.
> 
> Andere beobachten das Verhalten ja bei sich in der VM nicht.
> 
> Mir stellen sich da folgende Fragen:
> 
> Werden dabei Events getriggert, die dann nicht bearbeitet werden?
> 
> Ist deine VM so konfiguriert, dass hier sehr viele Events getriggert werden.
> 
> Leider hat der settle keine Verbose-Option.
> 
> Muss da mal - heute abend nicht mehr - Tante Google befragen.
> 
>> Der Eisfair-Kernel der VM weiss ja bereits, dass es auf einem
>> KVM-Hypervisor läuft. Siehe: /var/log/messages: "... eis klogd: Hypervisor
>> detected: KVM". (Der Kernel müsste diese Info "exportieren", somehow).
>> In den Startup-Scripts gibt es auch Möglichkeiten festzustellen, ob die
>> das System auf einem Hypervisor läuft (z.B. "dmidecode", ist im
>> Basis-Eisfair vorhanden). In diesem Falle, werden die beiden Befehle
>> _nicht_ aufgeführt.
>>
>> Falls Eisfair "bare metal" läuft, werden die Waits beibehalten. Alles
>> bleibt beim alten. Keine weitere Änderung erforderlich.
>>
>> Ich denke, das sollte ohne großen Aufwand möglich sein.
> 
> Es geht nicht um den Aufwand; für mich sind da einfach noch offene Fragen.
> 
>> Btw., Marcus: Hast Du in S03udev  diese Variable "OMIT_UDEV_SETTLE" im if
>> Statement gesehen, in der das "udevadm settle" eingebettet ist? Wo wird
>> diese Variable gesetzt und unter welchen Bedingungen?
> 
> Das habe ich mich auch gefragt und keine Antwort gefunden. Eventuell wird
> die von den trigger-Zeilen gesetzt, wenn diese Events triggern.
> 
> Das wird man aber auch in der Doku zu udev finden können.
>