Ich wecke ein Wunder in Bezug auf MONITOR-MWAIT vs HLT Anweisungen. Beide halten den Prozessor an, beide wachen bei verschiedenen externen Triggern auf (Interrupts usw.).
In meinen Experimenten funktionieren HLT und MWAIT fast gleich, wenn man sie berücksichtigt:
(MWAIT könnte sicherlich höher res sein, ich habe die Auflösung nicht gemessen, aber es scheint, dass es über-weckt-ups durch (ich nehme an) Interrupts und so) .. so kann ich nicht den großen Vorteil sehen.
Danke, Alle Gedanken auf diese Weise würden sehr geschätzt werden
Für die Leistung; Was am meisten zählt, ist die Zeit, die die CPU braucht, um aus ihrem "Warte" -Zustand zu kommen, wann auch immer darauf gewartet wird (ein IRQ für HLT oder entweder ein IRQ oder ein Speicherschreiben für MWAIT). Dies beeinflusst die Latenz - z. wie lange es dauert, bis ein Interrupt-Handler gestartet wird oder bevor tatsächlich ein Task-Wechsel stattfindet. Die Zeit, die eine CPU benötigt, um aus ihrem Wartezustand herauszukommen, ist für verschiedene CPUs unterschiedlich und kann auch für HLT und MWAIT auf derselben CPU leicht unterschiedlich sein.
Gleiches gilt für den Stromverbrauch - die während des Wartens verbrauchte Energie kann zwischen verschiedenen CPUs stark variieren (besonders wenn Sie über Dinge wie Hyper-Threading nachdenken); und der Stromverbrauch von HLT gegenüber MWAIT kann sich auf derselben CPU auch geringfügig unterscheiden.
Zur Verwendung sind sie für verschiedene Situationen gedacht. HLT dient zum Warten auf einen IRQ, während MWAIT zum Warten auf einen Speicherschreibvorgang wartet. Wenn Sie darauf warten, dass ein Speicher geschrieben wird, müssen Sie natürlich entscheiden, ob IRQs Ihr Warten unterbrechen sollen oder nicht (zB CLI dann MWAIT , wenn Sie nur auf einen Speicher schreiben wollen).
Für Multitasking-Systeme werden sie jedoch meistens nur für das selbe verwendet - in Schedulern, in denen die CPU im Leerlauf ist. Bevor MONITOR / MWAIT eingeführt wurde, benutzten Disponenten HLT, während sie auf die Arbeit warteten (um den Stromverbrauch ein wenig zu reduzieren). Das heißt, wenn eine andere CPU eine Task entsperrt, kann sie diese Aufgabe nicht einfach in die Schlange des Schedulers stellen und muss einen (relativ teuren) "Interprozessor-Interrupt" an die HLT-CPU senden, um sie aus ihrem HLT-Zustand zu bringen Die CPU wird nichts tun, wenn sie arbeiten kann / sollte. Mit MWAIT ist dieser "Interprozessor-Interrupt" (möglicherweise) nicht notwendig - Sie können MONITOR so einstellen, dass er Schreibvorgänge in der Warteschleife des Schedulers überwacht, so dass die Aufgabe der Task in die Warteschlange ausreicht, damit eine wartende CPU nicht mehr wartet .
Es wurde auch untersucht, ob MONITOR / MWAIT für Dinge wie Spinlocks und Synchronisation verwendet werden kann (z. B. Warten auf die Freigabe einer umstrittenen Sperre). Das Endergebnis dieser Untersuchung ist, dass die Zeit, die die CPU benötigt, um aus ihrem "Warte" -Zustand zu kommen, zu hoch ist und die Verwendung von MONITOR / MWAIT zu viel Leistungsverlust verursacht (es sei denn, es gibt Konstruktionsfehler - zB Spinlock) wenn du einen Mutex benutzen solltest.)
Ich kann mir keinen anderen Grund vorstellen (über Scheduler und Sperren / Synchronisation hinaus), HLT oder MWAIT zu verwenden.
Der HLT-Befehl implementiert den niedrigsten Leerlaufleistungszustand (C-State), der für einen einzelnen Thread verfügbar ist, während der MWAIT-Befehl es Ihnen ermöglicht, alle verfügbaren Leerlaufleistungszustände sowie Unterzustände anzufordern.
Auf der Hardwareebene entspricht die Ausführung von HLT der Ausführung von MWAIT mit einem Zustandshinweis von 0. Dies versetzt den Prozessor in den C1-Zustand, bei dem der Kern getaktet wird. Wenn Sie in tiefere C-States eintreten wollen, um das Kern-Gate und möglicherweise das Power-Gate des Pakets zu betreiben, müssen Sie MWAIT verwenden.
Es gibt immer einen Kompromiss zwischen Energieeinsparungen und Ausgangslatenz für verschiedene Energiezustände. Je tiefer der C-State, desto mehr Energieeinsparungen, aber desto länger dauert es, den C-State zu verlassen. Sie sollten auch beachten, dass moderne x86-Prozessoren die Tiefe des Energiezustands basierend auf der Häufigkeit von Unterbrechungen begrenzen (dh wenn Sie alle 1 us Unterbrechungsereignisse empfangen, versucht die Hardware nicht, einen C-Status mit einem 2-us-Ausgang einzugeben Latenz).
Zusätzlich zur Hardware, die den eingegebenen C-State blockiert, können einige C-States nur durch Koordination zwischen Threads eingegeben werden. Auf einem Intel x86-Prozessor mit Hyper-Threading müssen beispielsweise beide Threads in einem Core einen Power-Gating-C-State anfordern, damit Power-Gating auf der Core-Ebene stattfindet. Ebenso müssen alle Cores in einem Paket ein Paket anfordern. Level Power-Gated C-State für Power-Gating auf der Paketebene auftreten. Die Hardware hält sich im Allgemeinen an die flachste Anforderung. Wenn also ein Thread C1 anfordert und ein anderer C3 anfordert, gibt der Prozessor C1 ein.
Wenn Sie das Betriebssystem nicht steuern, dann ist es wirklich ein strittiger Punkt (da MWAIT nur bei CPL0 verfügbar ist). Wenn Sie das Betriebssystem "besitzen", wird es fast immer sinnvoll sein, MWAIT anstelle von HLT zu verwenden, da dies in vielen Fällen zu viel höheren Energieeinsparungen führt und den Zugriff auf den gleichen Ruhezustand wie HLT ermöglicht.
>MONITOR / MWAIT sollte für Dinge wie Spinlocks und Synchronisation verwendbar sein (z. B. warten, bis eine umstrittene Sperre ausgelöst wird).
Allerdings musste MONITOR / MWAIT (a) für einen erstaunlich dummen und nervigen Grund darauf beschränkt werden, nur von Ring 0 Kernel-Code, nicht Benutzercode verwendet zu werden, und (b) wurde mit Mikrocode geladen, um in eine niedrige Potenz zu gelangen Schlafzustände.
Einige Firmen haben ähnliche oder äquivalente Anweisungen besser implementiert, zum Beispiel MIPS 'LL / PAUSE entspricht ungefähr MONITOR / MWAIT.
Tags und Links assembly x86-64 cpu-architecture instruction-set