Zeitstempelzähler (TSC) beim Wechsel zwischen Kernel und Benutzermodus

Question

Ich frage mich, ob jemand mehr Details über den Zeitstempel-Zähler in Linux weiß, wenn ein Kontextwechsel stattfindet? Bis jetzt war ich der Meinung, dass der TSC-Wert in jedem Taktzyklus nur um 1 zunimmt, egal ob im Kernel oder im Benutzermodus. Ich habe jetzt die Leistung einer Anwendung mit dem TSC gemessen, die ein Leistungsergebnis von 5 Mio Cycles ergab. Dann habe ich einige Änderungen an dem Scheduler vorgenommen, was bedeutet, dass ein Kontextwechsel beträchtlich länger dauert, z. 2 Millionen Zyklen statt 500.000 Zyklen. Das Witzige ist, dass wenn man die Leistung der ursprünglichen Anwendung erneut misst, es immer noch 5 Millionen Zyklen dauert ... Ich frage mich also, warum es nicht wesentlich länger gedauert hat, da ein Context Switch nun fast 2 Mio Clock Cycles mehr braucht? (und es treten mindestens 3 Kontext während der Ausführung der Anwendung auf).

Ist der Zeitstempel-Zähler im Kernel-Modus irgendwie deaktiviert? Oder wird der Inhalt des TSC während der Wettbewerbswechsel gespeichert? Danke, wenn mir jemand zeigen könnte, was das Problem sein könnte!

Answer 1

Ich glaube, der TSC ist eigentlich ein Hardware-Konstrukt des Prozessors, den Sie verwenden. IE: Beim Lesen des TSC wird der RDTSC-Prozessor-Opcode verwendet. Ich denke nicht einmal, dass es eine Möglichkeit für das Betriebssystem gibt, seinen Wert zu ändern, es erhöht sich mit jedem Tick seit dem letzten Power-Reset.

In Bezug auf Ihre Änderungen an den Scheduler, ist es möglich, dass Sie einen Multi-Core-Prozessor in einer Weise verwenden, dass das Betriebssystem Ihren laufenden Prozess nicht ausschaltet? Sie könnten einen Anruf an sched_yield() oder sleep(0) in Ihrem Programm tätigen, um zu sehen, ob Ihre Scheduler-Änderungen wirksam werden.

Answer 2

Wie Sie auf Wikipedia

Mit dem Aufkommen von Multi-Core/Hyper-Threading-CPUs, Systemen mit mehreren CPUs lesen können, und „Winterschlaf“ Betriebssysteme kann der TSC nicht, um genaue Ergebnisse herangezogen werden. Das Problem besteht aus zwei Komponenten: der Tickrate und der Frage, ob alle Cores (Prozessoren) identische Werte in ihren Zeitmessregistern haben. Es gibt kein Versprechen, dass die Zeitstempel-Zähler von mehreren CPUs auf einem einzelnen Motherboard synchronisiert werden. In solchen Fällen können Programmierer nur zuverlässige Ergebnisse erzielen, indem sie ihren Code an eine einzige CPU binden. Selbst dann kann sich die CPU-Geschwindigkeit aufgrund von Energiesparmaßnahmen ändern, die vom Betriebssystem oder BIOS vorgenommen werden, oder das System kann in den Ruhezustand versetzt und später wieder aufgenommen werden (Zurücksetzen des Zeitstempelzählers). Das Vertrauen in den Zeitstempelzähler verringert auch die Portabilität, da andere Prozessoren möglicherweise keine ähnliche Funktion haben. Neuere Intel-Prozessoren enthalten einen TSC mit konstanter Rate (identifiziert durch das Flag constant_tsc in Linux/proc/cpuinfo). Bei diesen Prozessoren liest der TSC die maximale Rate des Prozessors unabhängig von der tatsächlichen CPU-Betriebsrate. Dies führt zwar zu einer gleichmäßigeren Zeiterfassung, kann jedoch Benchmarks verzerren, bei denen eine gewisse Zeit für die Hochlaufphase bei einer niedrigeren Taktrate verbraucht wird, bevor das Betriebssystem den Prozessor auf die höhere Rate schaltet. Dies hat den Effekt, dass die Dinge so aussehen, als würden sie mehr Prozessorzyklen benötigen, als sie es normalerweise tun würden.