Ich führe einige Benchmarks durch. Mein Benchmark-Läufer überwacht den Dmesg-Puffer zwischen den Experimenten auf mögliche Auswirkungen auf die Leistung. Heute warf es dies auf:
[2015-08-17 10:20:14 WARNUNG] dmesg scheint sich geändert zu haben! Diff folgt: --- 2015-08-17 09:55:00 +++ 2015-08-17 10:20:14 @@ -825,3 +825,4 @@ [3.802206] [drm] Aktivieren von RC6-Zuständen: RC6 ein, RC6p aus, RC6pp aus [7.900533] r8169 0000: 06: 00.0 eth0: link up [7.900541] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: Verbindung wird bereit + [236832.221937] Perf-Interrupt dauerte zu lange (2504> 2500) und senkte die Kernel.perf_event_max_sample_rate auf 50000
Nach einigem Suchen weiß ich jetzt, dass es sich um ein Profiling-Subsystem im Linux-Kernel handelt, das "perf" heißt. Ich glaube nicht, dass wir das brauchen, also würde ich es gerne komplett deaktivieren.
Bei erneuter Suche finde ich, dass das sysctl perf_cpu_time_max_percenthelfen könnte. Hier jemand schlägt vor , indem es auf 0 Lesen in diese etwas mehr zu deaktivieren hier :
perf_cpu_time_max_percent:
Hinweise zum Kernel, wie viel CPU-Zeit für die Verarbeitung von Perf-Sampling-Ereignissen verwendet werden soll. Wenn das perf-Subsystem darüber informiert wird, dass seine Samples diesen Grenzwert überschreiten, senkt es seine Sampling-Frequenz, um zu versuchen, die CPU-Auslastung zu reduzieren.
Einige Perf Sampling-Vorgänge finden in NMIs statt. Wenn die Ausführung dieser Beispiele unerwartet zu lange dauert, können die NMIs so weit nebeneinander liegen, dass nichts anderes ausgeführt werden darf.
0: Deaktiviere den Mechanismus. Überwachen oder korrigieren Sie die Abtastrate von perf nicht, egal wie viel CPU-Zeit erforderlich ist.
1-100: Versuch, die Abtastrate von perf auf diesen Prozentsatz der CPU zu drosseln. Hinweis: Der Kernel berechnet eine "erwartete" Länge jedes Beispielereignisses. 100 bedeutet hier 100% dieser erwarteten Länge. Auch wenn diese Option auf 100 eingestellt ist, wird möglicherweise weiterhin eine Beispieldrosselung angezeigt, wenn diese Länge überschritten wird. Setzen Sie den Wert auf 0, wenn es Ihnen wirklich egal ist, wie viel CPU verbraucht wird.
Das hört sich für mich so an, als würde 0 bedeuten, dass die Abtastrate der Profilerstellung nicht mehr überprüft wird, aber das freq-Subsystem läuft weiter (?).
Kann jemand Aufschluss darüber geben, wie die Kernel-Profilerstellung mit freq vollständig deaktiviert werden kann?
EDIT: Jemand schlug vor, einen Kernel ohne perf zu erstellen, aber ich denke nicht, dass dies überhaupt möglich ist. Die Option scheint nicht umschaltbar zu sein:
EDIT2: Nachdem ich mehr gelesen hatte, entschied ich, dass ich in der Lage sein könnte, kernel.perf_event_max_sample_rateauf Null zu setzen . Dh keine Abtastwerte pro Sekunde. Dies ist jedoch auch nicht möglich ( Quelle ):
commit 02f98e3e36da106338b7c732fed516420fb20e2a Autor: Knut Petersen Datum: Mittwoch, 25. September, 14:29:37 Uhr 2013 +0200 perf: Erzwinge 1 als Untergrenze für perf_event_max_sample_rate
EDIT 3: FWIW perf_cpu_time_max_percentist auf 25 gesetzt, was bedeutet, dass der Kernel mehr als 25% seiner Zeit mit dem Abtasten von Hardwareregistern verbracht hat. Dies ist für ein Benchmarking-Gerät nicht akzeptabel.
Ich bin mir jetzt sicher, dass das Setzen perf_cpu_time_max_percentauf Null die Situation nur verschlimmern würde, da der Kernel weiterhin über 25% seiner Zeit zum Lesen von Hardwareregistern benötigt. Der Fehler wird ausgelöst, um die Samplerate anzupassen. Auf diese Weise wird versucht, sicherzustellen, dass der Kernel seine Quote von <25% seiner Zeit in perf erfüllt. 25% ist meiner Meinung nach immer noch zu hoch.
Wenn ich perf wirklich nicht deaktivieren kann, wäre es wahrscheinlich der beste Kompromiss, perf_event_max_sample_rateauf 1 zu setzen .
EDIT4: Ein Freund schlug vor, dass ich die Bedeutung von möglicherweise falsch interpretiert habe perf_cpu_time_max_percent, sodass die obigen Aussagen möglicherweise falsch sind. Ein Wert von 25 gibt an, dass der Kernel mehr als 25% einer beliebigen Länge verwendet hat, die er für die Verarbeitung von Perf-Interrupts reserviert hat.
EDIT5:
Wie in den Kommentaren erwähnt, -*-deutet die Option against the perf darauf hin, dass die Funktion von einer anderen aktivierten Funktion erzwungen wird. Wenn ich reinschaue help, heißt es, welche Funktionen dies sind:
Ich glaube nicht, dass ich hier gewinnen kann. Die Boolesche Formel selected bysagt
Wenn Sie auf X86 abzielen oder ...
Ich habe gerade überprüft, ob das Targeting auf X86_64 tatsächlich möglich ist CONFIG_X86. Sobald Sie also X86 oder X86_64 als Ziel auswählen, erhalten Sie Perfektion.
Daher möchte ich meine Frage leicht ändern zu:
Welche Perf-Einstellungen kann ich verwenden, um den Zeitaufwand des Kernels für Perf-Routinen zu minimieren?
Beachten Sie, dass das übergeordnete Ziel darin besteht, zufällige Variationsquellen für das Benchmarking zu kontrollieren. Wie kann ich die Auswirkung auf Benchmarks minimieren, wenn ich Perf nicht deaktivieren kann?
CONFIG_HAVE_PERF_EVENTS=yund CONFIG_PERF_EVENTS=y. Ich glaube nicht, dass diese behinderte Leistung.
-*-bedeutet, dass ein Subsystem vom perf-Modul abhängt. HelpZeigt den Baum der Abhängigkeiten an, die Sie deaktivieren müssen, um die Option auf [*]oder zu ändern [M].