Wenn man sich unmögliche Aufgaben stellt, kann man nur scheitern

[abufrejoval]

"Running a use case in the host vs VM should not have any performance/power impact outside of
the virtualization overhead."

Das klingt erst mal schön, ist aber für echte VMs unerreichbar, seitdem Takte und Kerne variabel sind.

Das war zu Zeiten der IBM 360/67, wo die VMs ihren ersten Frühling erlebten, noch relativ einfach, weil die Takte statisch waren.

Mit Kernen, welche mal eben zwischen 50-5000MHz takten 0,5-50Watt verbraten und dann noch in zwei oder drei verschiedenen Varianten und neuerdings unterschiedlichen Cache-Konfigurationen auf einem SoC existieren und 1-8 Threads pro Kern verarbeiten können, ist schon der Kernel auf dem Host völlig überfordert und bräuchte mindestens ein Expertensystem, um hier auf die höchst variablen Wünsche der Eigentümer oder Anwender einzugehen, die noch dazu antagonistisch sein können.

Das kann durch eine Zwischenschicht durch Hypervisor und Gastkernel nicht besser werden, denn noch immer sind es Kernel gewohnt als Götter über die Maschine zu walten, die sie "sehen".

Hypervisor setzen schon lange auf Kollaborateure (guest agents) innerhalb der VMs, um ansatzweise zu erkennen, ob Speicher dort auch tatsächlich benutzt wird und "entwenden" den mittels "balloon driver" auch gern mal für den guten Zweck einer gleichmäßigeren Hardwareauslastung. Aber eigentlich hakt es an jeder Stelle und Cloud-Service-Provider verlegen große Teile sogenannter Kernelarbeit in DPUs und ihre intelligenten DC-Fabrics, sodaß der klassische Bare-Metal- aber auch der Guest-Kernel mehr oder weniger zum Bootstrapper verkommen.

Diese Cloud-Service-Provider verabschieden sich aber bei ihren Custom-SoCs auch von variablen Takten, heterogenen Kernen oder Multithreading, weil deren sinnvolle und sichere Nutzung nicht handhabbar ist: Statt dessen verteilt man die Lasten auf heterogene Container.

Ich bezweifle daß KVM auf batteriebetriebenen Raptor-Lake SoCs mit E und P Cores jemals halbwegs vernünftige Entscheidungen wird treffen können, bis die dafür nötigen Abstraktionen erfunden wurden und umgesetzt werden konnten, ist diese Hardware längst Geschichte.

Und was die viel wichtigere Frage anbelangt, "wie konfiguriere ich meine Software, damit sie Problem P mit Energiekosten E zum Zeitpunkt T gelöst hat?", dafür fehlen so ziemlich alle Voraussetzungen, vor allem wenn man noch GPUs oder sonstige Acceleratoren flexibel einsetzen kann.

Container sind die weit bessere Lösung für dieses angebliche VM-Problem. Die sind in der IaaS Abstraktion wie z.B. bei OpenVZ eher selten geworden und ggf. sollten diese mittels Hardwareunterstützung (z.B. separate Speicherverschlüsselung) robuster gemacht werden, aber das Scheduling und der größte Teil der Ressourcenverwaltung ist außerhalb der VM weit besser aufgehoben.

Tatsächlich ist die Kernel-/Userland-Abstraktion innerhalb der VM weitgehend sinnlos und "serverless" möglicherweise besser mit "unikernel" zu machen



1 mal bearbeitet, zuletzt am 03.04.23 14:01 durch abufrejoval.

[FreiGeistler]

abufrejoval schrieb:
--------------------------------------------------------------------------------
> 0,5-50Watt verbraten

Da fehlt eine 1.

[M.P.]

Ach, bei heutigen Prozessoren kann das hinkommen ... insbesondere bei den Big/Little Designs,

Weder halte ich es für unwahrscheinlich, dass kein aktueller Intel-Kern mehr als 50 Watt verbrät (also bei einem 8-Kerner 400 Watt ...) und dass man x64 Kerne entsprechend auf 0,5 Watt drosseln kann halte ich auch nicht für unwahrscheinlich ...

Bei Atom-Kernen erst Recht ...

[Harryhh]

Dass das unmöglich ist darfst du aber keinesfalls dem Torvalds verraten, sonst wirft er die Scheduler-Patches die im 6er Kernel gelandet sind direkt wieder raus... ;)
Klar ist der Nest-Scheduler noch im Forschungsstadium, aber da müsste es eigentlich nur noch ein bisschen Fleißarbeit sein den Host-Kernel und die Gast-Kernel so weit miteinander kommunizieren zu lassen, dass Nest auch die Gäste korrekt berücksichtigen kann.

[gunterkoenigsmann]

Ob wir einen Seitenkanalangriff durch den Wechsel einer cm von big auf little erleben werden? Komplex genug ist das Problem, dass man irgendwas übersehen könnte...