Sto eseguendo alcuni benchmark. Il mio benchmark runner monitora il buffer dmesg tra gli esperimenti, cercando qualsiasi cosa che possa influire sulle prestazioni. Oggi ha vomitato questo:
[2015-08-17 10:20:14 ATTENZIONE] dmesg sembra essere cambiato! Diff segue: --- 2015-08-17 09:55:00 +++ 2015-08-17 10:20:14 @@ -825,3 +825,4 @@ [3.802206] [drm] Abilitazione stati RC6: RC6 acceso, RC6p spento, RC6pp spento [7.900533] r8169 0000: 06: 00.0 eth0: collegamento in alto [7.900541] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: il collegamento diventa pronto + [236832.221937] perf interrupt ha impiegato troppo tempo (2504> 2500), abbassando kernel.perf_event_max_sample_rate a 50000
Dopo alcune ricerche, ora so che si tratta di un sottosistema di profilazione nel kernel di Linux chiamato "perf". Non penso che ne abbiamo bisogno, quindi vorrei disabilitarlo del tutto.
Cercando di nuovo, trovo che il sistema perf_cpu_time_max_percentpotrebbe aiutare. Qui qualcuno suggerisce di disabilitare impostandolo su 0. Leggendo questo qui un po 'di più :
perf_cpu_time_max_percent:
Indica al kernel quanto tempo CPU dovrebbe essere consentito per gestire gli eventi di campionamento perf. Se il sottosistema perf viene informato che i suoi campioni stanno superando questo limite, diminuirà la frequenza di campionamento per tentare di ridurre l'utilizzo della CPU.
Alcuni campionamenti perf si verificano negli NMI. Se l'esecuzione inaspettata di questi campioni impiega troppo tempo, gli NMI possono essere impilati uno accanto all'altro così tanto che non è permesso eseguire nient'altro.
0: disabilita il meccanismo. Non monitorare o correggere la frequenza di campionamento di perf, indipendentemente dal tempo impiegato dalla CPU.
1-100: tenta di limitare la frequenza di campionamento di perf a questa percentuale di CPU. Nota: il kernel calcola una lunghezza "prevista" di ciascun evento di esempio. 100 qui significa il 100% della lunghezza prevista. Anche se impostato su 100, è possibile che venga comunque visualizzato il throttling del campione se questa lunghezza viene superata. Impostare su 0 se davvero non ti interessa quanta CPU viene consumata.
Mi sembra che 0 significhi che la frequenza di campionamento del profilo non è più controllata, ma il sottosistema freq rimane in esecuzione (?).
Qualcuno può fare luce su come disabilitare completamente la profilazione del kernel con freq?
EDIT: Qualcuno mi ha suggerito di provare a compilare un kernel senza perf, ma non credo sia nemmeno possibile. L'opzione non sembra commutabile:
EDIT2: dopo ulteriori letture, ho deciso che avrei potuto essere impostato kernel.perf_event_max_sample_ratesu zero. Cioè nessun campione al secondo. Tuttavia, non puoi farlo neanche ( fonte ):
commit 02f98e3e36da106338b7c732fed516420fb20e2a Autore: Knut Petersen Data: mercoledì 25 settembre 14:29:37 2013 +0200 perf: imponi 1 come limite inferiore per perf_event_max_sample_rate
EDIT 3: FWIW, perf_cpu_time_max_percentè impostato su 25, il che significa che il kernel impiegava oltre il 25% del suo tempo a campionare i registri hardware. Questo è inaccettabile per una macchina di benchmarking.
Ora sono sicuro che l'impostazione perf_cpu_time_max_percentsu zero peggiorerebbe solo la situazione, poiché il kernel continuerebbe a utilizzare oltre il 25% del tempo necessario per leggere i registri hardware. L'errore si attiva per regolare la frequenza di campionamento, cercando così di garantire che il kernel soddisfi la sua quota di utilizzo di <25% del suo tempo in perf. Il 25% è ancora troppo alto IMHO.
Se davvero non riesco a disabilitare perf, probabilmente il miglior compromesso sarebbe impostare perf_event_max_sample_ratesu 1.
EDIT4: Un amico ha suggerito che potrei aver frainteso il significato di perf_cpu_time_max_percent, quindi le affermazioni di cui sopra potrebbero essere errate. Un valore di 25 indica che il kernel ha usato più del 25% di una lunghezza arbitraria che aveva riservato per la manutenzione degli interrupt perf.
EDIT5:
Come sottolineato nei commenti, l' -*-opzione contro l'opzione perf suggerisce che la funzione è forzata da un'altra funzione abilitata. Se guardo dentro help, dice quali sono queste caratteristiche:
Non credo di poter vincere qui. La formula booleana selected bydice
Se stai scegliendo come target X86 o ...
Ho appena verificato che il targeting X86_64 lo abiliti davvero CONFIG_X86. Quindi sembra che non appena si bersaglia X86 o X86_64, si ottiene perf.
Quindi vorrei cambiare leggermente la mia domanda in:
Quali impostazioni perf posso usare per ridurre al minimo il tempo impiegato dal kernel nelle routine perf?
Tenere presente che l'obiettivo generale è controllare le fonti di variazione casuale per l'analisi comparativa. Se non riesco a disabilitare perf, come posso minimizzare il suo impatto sui benchmark?
CONFIG_HAVE_PERF_EVENTS=ye CONFIG_PERF_EVENTS=y. Non penso che questo perf disabilitato.
-*-indica che alcuni sottosistemi dipendono dal modulo perf. Helpmostra l'albero delle dipendenze che è necessario disabilitare per modificare l'opzione in [*]o [M].