In een verrassende wending van gebeurtenissen duwde een NVIDIA -ingenieur een oplossing voor de Linux -kernel, waarbij een prestatieregressie werd opgelost op AMD geïntegreerde en speciale GPU -hardware (via Phoronix). Blijkt dat dezelfde ingenieur het probleem in de eerste plaats per ongeluk heeft geïntroduceerd met een reeks wijzigingen in de kernel vorige week, in een poging om de PCI -barruimte te verhogen tot meer dan 10 tib. Dit werd de GPU ten onrechte aangemaakt als beperkte en belemmerende prestaties, maar gelukkig werd het snel opgepikt en opgelost.
In het open-source paradigma is het een ongeschreven regel om te repareren wat je breekt. De Linux-kernel is open-source en accepteert bijdragen van iedereen, die vervolgens worden beoordeeld. Verwacht wordt dat verantwoordelijke bijdragers zullen helpen bij het oplossen van kwesties die voortvloeien uit hun wijzigingen. Dus, ondanks hun rivaliteit in de GPU -markt, is Foss (gratis open source software) een weg die de kloof tussen AMD en NVIDIA overbrugt.
De regressie werd veroorzaakt door een commit die bedoeld was om de PCI -staafruimte te verhogen boven 10TIB, waarschijnlijk voor systemen met grote geheugenruimtes. Dit verminderde indirect een factor genaamd KASLR -entropie op consumenten X86 -apparaten, die de willekeur bepaalt van waar de gegevens van de kernel voor beveiligingsdoeleinden in het geheugen worden geladen. Tegelijkertijd heeft dit ook het bereik van het toegankelijke geheugen van de kernel (direct_map_physmem_end) kunstmatig opgeblazen, meestal tot 64TIB.
In Linux is het geheugen verdeeld in verschillende zones, waarvan er één het zone -apparaat is dat kan worden geassocieerd met een GPU. Het probleem hier is dat wanneer de kernel zone -apparaatgeheugen zou initialiseren voor Radeon GPU’s, een bijbehorende variabele (max_pfn) die het totale adresseerbare RAM door de kernel weergeeft, kunstmatig zou stijgen tot 64TIB.
Aangezien de GPU waarschijnlijk geen toegang heeft tot het gehele 64TIB -bereik, zou het DMA_Addressing_Limited () als waar markeren. Deze variabele beperkt in wezen de GPU om de DMA32 -zone te gebruiken, die slechts 4 GB geheugen biedt en de prestatieregressies verklaart.
Het goede nieuws is dat deze oplossing moet worden geïmplementeerd zodra het pull-aanvraag landt, vlak voordat het Linux 6.15-RC1-venster vandaag wordt gesloten. Met een algemene cadans van zes tot acht weken vóór nieuwe Linux -kernels kunnen we verwachten dat de stabiele 6.15 -release rond eind mei of begin juni beschikbaar zal zijn.
