CPU-TSC-Abrufvorgang, insbesondere in Umgebungen mit mehreren Kernen und mehreren Prozessoren

In der Linux-Welt kann man Folgendes verwenden, um Timer/Clockticks mit Nanosekunden-Präzision zu erhalten:

#include <sys/time.h>

int foo()
{
   timespec ts;

   clock_gettime(CLOCK_REALTIME, &ts); 
   //--snip--      
}

Diese Antwort schlägt vor asm Ansatz zur direkten Abfrage der CPU-Uhr mit dem RDTSC Anweisung.

Wie werden in einer Architektur mit mehreren Kernen und mehreren Prozessoren diese Takte/Timerwerte über mehrere Kerne/Prozessoren hinweg synchronisiert? Meines Wissens nach wird dort inhärent eingezäunt. Ist dieses Verständnis richtig?

Können Sie eine Dokumentation vorschlagen, die dies im Detail erklärt? Ich interessiere mich für Intel Nehalem und Sandy Bridge Mikroarchitekturen.

BEARBEITEN

Die Beschränkung des Prozesses auf einen einzelnen Kern oder eine CPU ist keine Option, da der Prozess wirklich riesig ist (in Bezug auf die verbrauchten Ressourcen) und alle Ressourcen in der Maschine, die alle Kerne und Prozessoren umfasst, optimal nutzen möchte.

Bearbeiten

Vielen Dank für die Bestätigung, dass der TSC über Kerne und Prozessoren hinweg synchronisiert ist. Aber meine ursprüngliche Frage ist, wie wird diese Synchronisation durchgeführt? ist es mit einer Art Zaun? Kennen Sie öffentliche Dokumente?

Fazit

Vielen Dank für alle Inputs: Hier ist die Schlussfolgerung für diese Diskussion: Die TSCs werden bei der Initialisierung mit einem RESET synchronisiert, der über die Kerne und Prozessoren in einem Multiprozessor-/Multicore-System erfolgt. Und danach ist jeder Kern auf sich allein gestellt. Die TSCs werden mit einem Phasenregelkreis invariant gehalten, der die Frequenzvariationen und somit die Taktvariationen normalisieren würde innerhalb eines bestimmten Kerns und so bleibt der TSC über Kerne und Prozessoren hinweg synchron.

Direkt von Intel, hier ist eine Erklärung, wie neuere Prozessoren einen TSC aufrechterhalten, der mit einer konstanten Rate tickt, zwischen Kernen und Paketen auf einem Multi-Socket-Motherboard synchron ist und sogar weiter ticken kann, wenn der Prozessor in einen Tiefschlaf-C-Zustand wechselt , siehe insbesondere die Erklärung von Vipin Kumar EK (Intel):

http://software.intel.com/en-us/articles/best-timing-function-for-measuring-ipp-api-timing/

Hier ist eine weitere Referenz von Intel, in der die Synchronisierung des TSC über Kerne hinweg diskutiert wird. In diesem Fall erwähnen sie die Tatsache, dass rdtscp es Ihnen ermöglicht, sowohl den TSC als auch die Prozessor-ID atomar zu lesen. Dies ist wichtig für die Ablaufverfolgung von Anwendungen … nehmen Sie an, Sie möchten verfolgen die Ausführung eines Threads, der von einem Kern zum anderen migrieren könnte, wenn Sie dies in zwei separaten Anweisungen (nicht atomar) tun, dann haben Sie keine Gewissheit, in welchem ​​​​Kern sich der Thread befand, als er die Uhr las.

http://software.intel.com/en-us/articles/intel-gpa-tip-cannot-sychronize-cpu-timestamps/

Alle Sockel/Gehäuse auf einem Motherboard erhalten zwei externe gemeinsame Signale:

1. ZURÜCKSETZEN
2. Referenz UHR

Alle Sockel sehen RESET gleichzeitig, wenn Sie das Motherboard mit Strom versorgen, alle Prozessorpakete erhalten ein Referenztaktsignal von einem externen Quarzoszillator und die internen Takte im Prozessor werden in Phase gehalten (allerdings normalerweise mit einem hohen Multiplikator, wie 25x). Schaltung namens Phase Locked Loop (PLL). Neuere Prozessoren takten den TSC mit der höchsten Frequenz (Multiplikator), die für den Prozessor ausgelegt ist (sogenannter konstanter TSC), unabhängig vom Multiplikator, den ein einzelner Kern aufgrund von Temperatur- oder Energiemanagement-Drosselung verwendet (sogenannter invarianter TSC). Nehalem-Prozessoren wie der im Jahr 2008 veröffentlichte X5570 (und neuere Intel-Prozessoren) unterstützen einen „Non-Stop-TSC“, der auch dann weiter tickt, wenn er in einem tief heruntergefahrenen C-Zustand (C6) Strom spart. Weitere Informationen zu den verschiedenen Ausschaltzuständen finden Sie unter diesem Link:

http://www.anandtech.com/show/2199

Bei weiteren Recherchen bin ich auf ein Patent gestoßen, das Intel am 22.12.2009 eingereicht und am 23.6.2011 veröffentlicht hat mit dem Titel „Controlling Time Stamp Counter (TSC) Offsets For Mulitple Cores And Threads“

http://www.freepatentsonline.com/y2011/0154090.html

Google-Seite für diese Patentanmeldung (mit Link zur USPTO-Seite)

http://www.google.com/patents/US20110154090

Soweit ich weiß, gibt es einen TSC im Uncore (die Logik in einem Paket, das die Kerne umgibt, aber nicht Teil eines Kerns ist), der bei jedem externen Bustakt um den Wert im Feld des von Vipin Kumar angegebenen maschinenspezifischen Registers erhöht wird im obigen Link (MSR_PLATFORM_INFO[15:8]). Der externe Bustakt läuft mit 133,33 MHz. Darüber hinaus hat jeder Kern sein eigenes TSC-Register, das von einer Taktdomäne getaktet wird, die von allen Kernen gemeinsam genutzt wird und sich von der Uhr für einen beliebigen Kern unterscheiden kann. Daher muss es eine Art Puffer geben, wenn der Kern-TSC vom RDTSC gelesen wird (oder RDTSCP)-Anweisung, die in einem Kern ausgeführt wird. Beispiel: MSR_PLATFORM_INFO[15:8] auf einem Paket auf 25 gesetzt werden kann, erhöht jeder Bustakt den Nichtkern-TSC um 25, es gibt eine PLL, die den Bustakt mit 25 multipliziert und diesen Takt jedem der Kerne zur Verfügung stellt, um ihr lokales TSC-Register zu takten, wodurch alle TSC beibehalten werden registriert sich synchron. Um also die Terminologie der tatsächlichen Hardware zuzuordnen

• Constant TSC wird implementiert, indem der externe Bustakt verwendet wird, der bei 133,33 MHz läuft, der mit einem konstanten Multiplikator multipliziert wird, der in MSR_PLATFORM_INFO angegeben ist[15:8]
• Invarianter TSC wird implementiert, indem der TSC in jedem Kern in einer separaten Taktdomäne gehalten wird
• Non-Stop-TSC wird implementiert, indem ein Uncore-TSC vorhanden ist, der durch MSR_PLATFORM_INFO inkrementiert wird[15:8] tickt bei jedem Bustakt, auf diese Weise kann ein Multi-Core-Paket tief heruntergefahren werden (C6-Zustand) und die PLL herunterfahren … es besteht keine Notwendigkeit, einen Takt auf dem höheren Multiplikator zu halten. Wenn ein Kern aus dem C6-Zustand wieder aufgenommen wird, wird sein interner TSC auf den Wert des Nichtkern-TSC (derjenige, der nicht in den Ruhezustand gegangen ist) mit einer Offset-Anpassung initialisiert, falls die Software einen Wert in den TSC geschrieben hat, die Details von die im Patent stehen. Wenn Software in den TSC schreibt, dann ist der TSC für diesen Kern gegenüber anderen Kernen phasenverschoben, aber mit einem konstanten Offset (die Frequenz der TSC-Takte sind alle durch einen konstanten Multiplikator an den Bus-Referenztakt gebunden).

Auf neueren CPUs (i7 Nehalem+ IIRC) wird der TSC über alle Kerne hinweg synchronisiert und läuft mit konstanter Rate. Für einen einzelnen Prozessor oder mehr als einen Prozessor auf einem einzelnen Gehäuse oder Mainboard (!) können Sie sich also auf einen synchronisierten TSC verlassen.

Aus dem Intel Systemhandbuch 16.12.1

Der Zeitstempelzähler in neueren Prozessoren kann eine Verbesserung unterstützen, die als invarianter TSC bezeichnet wird. Die Prozessorunterstützung für invariantes TSC wird durch CPUID.80000007H:EDX angegeben[8]. Der invariante TSC wird in allen ACPI P-, C- mit einer konstanten Rate ausgeführt. und T-Zustände. Dies ist das architektonische Verhalten, das sich vorwärts bewegt.

Auf älteren Prozessoren kann man sich weder auf konstante Rate noch auf Synchronisation verlassen.

Bearbeiten: Zumindest auf mehreren Prozessoren in einem einzigen Paket oder Mainboard wird der invariante TSC synchronisiert. Der TSC wird bei einem /RESET auf Null zurückgesetzt und tickt dann mit einer konstanten Rate auf jedem Prozessor ohne Drift weiter. Das /RESET-Signal kommt garantiert zur gleichen Zeit an jedem Prozessor an.

RTDSC nicht CPU-übergreifend synchronisiert. Daher können Sie sich in Multiprozessorsystemen nicht darauf verlassen. Die einzige Problemumgehung, die mir für Linux einfällt, besteht darin, den Prozess tatsächlich so zu beschränken, dass er auf einer einzelnen CPU ausgeführt wird, indem seine Affinität eingestellt wird. Dies kann extern mit using erfolgen taskset Dienstprogramm oder “intern” mit sched_setaffinity oder pthread_setaffinity_np Funktionen.

Dieses Handbuch, Kapitel 17.12, beschreibt die in den neuesten Prozessoren verwendete invariante TSC. Dieser bei Nehalem verfügbare Zeitstempel ermöglicht zusammen mit der rtscp-Anweisung das Lesen eines Zeitstempels (der nicht von Wartezuständen usw. beeinflusst wird) und einer Prozessorsignatur in einer atomaren Operation.

Es soll sich für die Berechnung der Wall-Clock-Zeit eignen, erwartet aber offensichtlich nicht, dass der Wert auf allen Prozessoren gleich ist. Die erklärte Idee ist, dass Sie sehen können, ob aufeinanderfolgende Lesevorgänge auf die gleiche CPU-Uhr erfolgen, oder um sich an mehrere CPU-Lesevorgänge anzupassen. “Es kann auch verwendet werden, um Unterschiede in den TSC-Werten pro CPU in einem NUMA-System auszugleichen.”

Siehe auch rdtsc-Genauigkeit über CPU-Kerne hinweg

Ich bin mir jedoch nicht sicher, ob die endgültige Konsistenzschlussfolgerung in der akzeptierten Antwort aus der Aussage folgt, dass der tsc für die Uhrzeit der Wanduhr verwendet werden kann. Wenn es konsistent wäre, welchen Grund würde es geben, die CPU-Quelle der Zeit atomar zu bestimmen?

Hinweis: Die TSC-Informationen wurden in diesem Intel-Handbuch von Kapitel 11 nach Kapitel 17 verschoben.