Windows-Thread-Zeitplan für Zeitplan ändern

910
xakepp35

Bei dieser Frage geht es um die Möglichkeit, den Windows-Kernel in Echtzeit wie Oesen und seine Möglichkeiten zu optimieren. Es ist ein ganz bestimmtes enges Thema, das ein tiefes Wissen erfordert - Sie wissen es entweder nicht.

Ich bin auf der WS2016 x64-Plattform und kann die Timerauflösung nur auf 500us (0,5 ms) einstellen, wobei die NtSetTimerResolution()Funktion innerhalb der ntdll.dllBibliothek aufgerufen wird . Ich denke, dieser Wert ist an Zeitplaner des Zeitplaners gebunden.

Allerdings mag ich es 100us erhöhen . Mess könnte beinhalten Aufruf NtDelayExecution()in gewickelte QueryPerformanceCounter()Anrufen oft innerhalb der Schleife und dann Statistiken wie Jitter, Standardabweichung der Analyse so weiter.

Wie soll das gehen? Gibt es irgendeinen Registry- / File-Tweak, bei dem ich das Fenster des Zeitplanes einstellen kann?


PS. Einige Leute fragen möglicherweise " Warum brauchen Sie es? " Oder sagen "Nicht tun, es ist falsch! ". Ich verstehe solche Gedanken und würde voraus antworten.

  • Dies ist nur ein Software-Experiment. Es ist nur zum Testen von Möglichkeiten und körperlichen Ergebnissen.
  • Ich bin mir bewusst, dass dies zu potenziellen Problemen führen kann, z. B. zusätzliche CPU-Zeit, die nur bei Kontextwechseln verschwendet wird, Systeminstabilität, Unverantwortlichkeit, Datenverlust und alle möglichen Probleme, die dadurch entstehen könnten. Ich akzeptiere alle negativen Konsequenzen, wenn Sie dies im Voraus tun und alle Verantwortung übernehmen. Selbst wenn Rauch und Funken aus meiner Maschine kommen würden :)
  • Wie beim Googeln oder Durchsuchen hier - ofc Ich habe es bereits getan und keine nützlichen Informationen gefunden, da dieses Thema ziemlich eng ist und sich auf die Funktion der OS-Abwickler bezieht. Und fast sinnlos auf jeder Windows-Maschine. Ich weiß, dass ich es nicht in Echtzeit drehen kann. Diese Site-Suche "Zeitplan für Zeitplan" liefert kein Ergebnis.
1

1 Antwort auf die Frage

0
Jamie Hanrahan

Das Scheduler-Zeitintervall wird nicht direkt von der Timerauflösung beeinflusst. Für die meisten Prozesse auf den Client-SKUs sind es 20 ms. Für einen Prozess, dem das Vordergrundfenster gehört, sind es 60 ms. Diese Werte betragen in der Regel 120 ms für Server-SKUs.

Diese Werte sind unabhängig davon, was Sie mit NtSetTimerResolution tun. Unabhängig von der Timerauflösung wird eine geeignete Anzahl von Timer-Taktinterrupts gezählt, bevor ein 20-ms-Intervall erkannt wird und der Scheduler den "Quantenzähler" des aktuellen Threads usw. dekrementiert.

Wenn Sie die Zeitgeberauflösung auf 100 usec verbessern, hat dies keine Auswirkungen auf die Thread-Planung. Es wird jedoch zusätzlicher Overhead erzeugt, was bei 5x der vorherigen Anzahl von Aufrufen der Routine, die prüft, ob Timer abgelaufen sind, besteht.

Es gibt keine Registrierung oder andere Änderungen, um dies zu ändern.

Es gibt einen Registry-Hack, der verwendet werden kann, um die "Timelice-Dehnung", die auf Client-SKUs auftritt, zu unterdrücken, oder um ein Serversystem dazu zu bringen, sich wie ein Client zu verhalten, und umgekehrt, was die Timelice-Länge angeht. Und manchmal (aufgrund eines kleinen Fadens von Thread-> Quantum, wenn ein Thread aus dem Warten kommt) sind die Zeitfenster möglicherweise etwas kürzer, als es "hätte" sollen. Es gibt jedoch keine Möglichkeit, die Zeitscheibe auf weniger als 20 ms oder auf ein Vielfaches von 20 ms einzustellen, und es sind nicht viele verschiedene Vielfache verfügbar.

Beachten Sie, dass das Scheduler-Zeitintervall keinen Einfluss auf die Vorbelegung hat. Wenn die Wartezeit eines Threads behoben ist und die Priorität des Threads höher ist als die des aktuell ausgeführten Threads auf dem idealen Prozessor des neuen Threads, wird der letztere Thread sofort verdrängt . Es darf nicht bis zum Ende seiner Zeitscheibe laufen, bevor es gemimpt wird. Zeitscheiben sind nur wichtig, wenn mehrere Threads mit derselben Priorität konkurrieren.

Quelle: Das meiste davon findet sich in Windows Internals von Solomon, Russinovich et al .

Sogar über das Hex-Editieren einiger Binaries, wenn es aus Versehen irgendwo innerhalb des Windows-Kernels kompiliert wurde? Dann wird es eine Frage, 4 oder 8 Bytes zu finden und sie zu optimieren. Dies kann nicht unmöglich sein, da es sich nicht um ein Hardwareproblem handelt, sondern um ein Softwareproblem. Und es ist definitiv eine Art OS-Tweak, obwohl es möglicherweise nicht direkt durch die Registrierung angezeigt wird. Wo soll ich mit der Suche beginnen? xakepp35 vor 6 Jahren 0
Soweit ich im Quellcode von Reactos sehen kann (beste Vermutung, dass wir den Quellcode geöffnet haben) [[NtQueryTimerResolution () `gibt nur einige Ganzzahlen zurück] (https://doxygen.reactos.org/df/d59/ntoskrnl_2ex_2time_8c_source.html#l00481.) ) die in der [KeSetTimeIncrement () - Funktion] geändert wurden (https://doxygen.reactos.org/d0/db9/ntoskrnl_2ke_2clock_8c_source.html#l00228) xakepp35 vor 6 Jahren 0