Risolve il grave degrado delle prestazioni di Linux osservato da Torvalds

Prima che Linus Torvalds perdesse Internet e l'elettricità a causa di una tempesta di neve che incideva sulla finestra di integrazione di Linux 6.8, il suo fine settimana era già in condizioni difficili a causa di un calo di prestazioni con il nuovo codice Linux 6.8 che stava causando la creazione del suo kernel Linux. È il doppio rispetto ai core precedenti. Un ingegnere AMD Linux è stato in grado di riprodurre la regressione e, con gli sviluppatori principali, ora esiste una soluzione confermata a questo problema nell'ultimo codice di pianificazione.

Nella discussione sulla significativa regressione delle prestazioni riportata da Linus Torvalds derivante dalle modifiche allo scheduler in Linux 6.8, per lo split commit, non è stato immediatamente chiaro allo sviluppatore coinvolto cosa avesse causato la regressione. Nella discussione successiva è intervenuto Wise Carney di AMD menzionato Può anche riprodurre la regressione. Invece di un AMD Ryzen Threadripper di fascia alta come quello utilizzato da Torvalds, Wyes utilizzava un modesto desktop AMD Ryzen 5600G. Una nota importante che ha sollevato è che questo viene riprodotto solo se si disabilita ACPI CPPC dal BIOS e si utilizza ACPI CPUFreq con il governatore Schedutil.

La maggior parte dei sistemi AMD Zen 2 e successivi supportano ACPI CPPC, quindi con i core moderni sul lato Ryzen utilizzano in genere il nuovo driver AMD P-State. Ma per Zen 2/Zen 3 e sistemi precedenti (o quelli che disabilitano CPPC dal BIOS), il driver CPUFreq viene ancora utilizzato e il regolatore di frequenza della CPU predefinito è solitamente “Schedutil” per sfruttare i dati di utilizzo dello scheduler.

Attraverso questo thread sulla mailing list è stata suggerita una correzione e sono stati discussi problemi specifici relativi a questa regressione. Alla fine, Vincent Guiteau credette di avere una soluzione alla regressione e Wise riuscì a testare con successo la patch.

Guittot è stato inviato Programmato/Fiera: correzione della selezione della frequenza per casi instabili Come patch per correggere questa brutta regressione sul nuovo codice Linux 6.8 quando si utilizza ACPI CPUFreq + Schedutil. Spiega con correzione:

“Quando la persistenza della frequenza non è abilitata, get_capacity_ref_freq(policy) restituisce la frequenza corrente e il margine prestazionale applicato da map_util_perf(), consentendo all'utilizzo di superare la capacità di calcolo massima e selezionare una frequenza superiore a quella corrente.

Il margine prestazionale viene ora applicato all'inizio della pipeline per tenere conto di alcuni vincoli di utilizzo e non possiamo ottenere un utilizzo superiore alla capacità di calcolo massima.

Dobbiamo utilizzare una frequenza superiore a quella corrente per avere la possibilità di impostare un OPP più alto quando la frequenza corrente è completamente utilizzata. Applica lo stesso margine e restituisce una frequenza superiore del 25% rispetto alla frequenza attuale per passare all'OPP successivo prima di utilizzare l'intera CPU del processore attuale.”

Alla fine, è stata una correzione del codice su una riga per risolvere questo degrado delle prestazioni che ha causato l'aumento delle build vuote del kernel di Linus Torvalds da 22 secondi a 44 secondi.

Supponendo che tutto continui a funzionare bene con la nuova patch, la correzione dovrebbe farsi strada nel codice Git di Linux 6.8 una volta ripristinate Internet e l'elettricità di Linus Torvalds.