Voordat Linus Torvalds zijn internet en stroom verloor als gevolg van een sneeuwstorm en daarmee de Linux 6.8-integratieperiode beïnvloedde, was zijn weekend al in slechte staat vanwege een prestatiedip met de nieuwe Linux 6.8-code die ervoor zorgde dat zijn Linux-kernel werd gebouwd. Het is het dubbele van wat het was met eerdere kernen. Een AMD Linux-ingenieur kon de regressie reproduceren en samen met de hoofdontwikkelaars is er nu een bevestigde oplossing voor dit probleem in de nieuwste planningscode.
Bij de bespreking van de significante prestatieregressie gerapporteerd door Linus Torvalds die voortkwam uit plannerwijzigingen in Linux 6.8, voor split commit, was het voor de betrokken ontwikkelaar niet meteen duidelijk wat de regressie veroorzaakte. In de daaropvolgende discussie sprak AMD's Wise Carney genoemd Het kan ook regressie reproduceren. In plaats van een high-end AMD Ryzen Threadripper zoals Torvalds gebruikt, gebruikte Wyes een bescheiden AMD Ryzen 5600G-desktop. Een belangrijke opmerking die hij naar voren bracht is dat dit alleen wordt gereproduceerd als je ACPI CPPC uitschakelt in het BIOS en ACPI CPUFreq gebruikt met de Schedutil-regelaar.
De meeste AMD Zen 2 en latere systemen ondersteunen ACPI CPPC, dus met moderne cores aan de Ryzen-kant gebruiken ze doorgaans de nieuwe AMD P-State-driver. Maar voor Zen 2/Zen 3 en eerdere systemen (of systemen die CPPC uitschakelen vanuit het BIOS) wordt het CPUFreq-stuurprogramma nog steeds gebruikt en is de standaard CPU-frequentieregelaar meestal “Schedutil” om te profiteren van de gebruiksgegevens van de planner.
Via deze draad op de mailinglijst werd een correctie voorgesteld en werden specifieke problemen met deze regressie besproken. Uiteindelijk geloofde Vincent Guiteau dat hij een oplossing voor de regressie had en kon Wise de patch met succes testen.
Guittot is nu verzonden Gepland/redelijk: frequentieselectie voor onstabiel geval repareren Als patch om deze slechte regressie op nieuwe Linux 6.8-code te verhelpen bij gebruik van ACPI CPUFreq + Schedutil. Legt uit met correctie:
“Als frequentiepersistentie niet is ingeschakeld, retourneert get_capacity_ref_freq(policy) de huidige frequentie en de prestatiemarge toegepast door map_util_perf(), waardoor het gebruik de maximale rekencapaciteit kan overschrijden en een frequentie kan selecteren die hoger is dan de huidige frequentie.
De prestatiemarge wordt nu vroeg in de pijplijn toegepast om rekening te houden met enkele gebruiksbeperkingen en we kunnen het gebruik niet boven de maximale rekencapaciteit krijgen.
We moeten een frequentie gebruiken die hoger is dan de huidige frequentie om kans te maken op een hogere OPP wanneer de huidige frequentie volledig wordt gebruikt. Pas dezelfde marge toe en retourneer een frequentie die 25% hoger is dan de huidige frequentie om over te schakelen naar de volgende OPP voordat we de volledige CPU in de huidige processor opgebruiken.”
Uiteindelijk was het een codeoplossing van één regel om deze prestatieverslechtering aan te pakken, waardoor de lege kernelbuilds van Linus Torvalds toenamen van 22 seconden naar 44 seconden.
Ervan uitgaande dat alles goed blijft testen met de nieuwe patch, zou de oplossing zijn weg moeten vinden naar Linux 6.8 Git-code zodra het internet en de elektriciteit van Linus Torvalds zijn hersteld.
‘Reader. Furious humble travel enthusiast. Extreme food scientist. Writer. Communicator.’
