Soluția Linux veche de 20 de ani încă încetinește sistemele AMD

Cipul de server Epyc de a doua generație de la AMD, este posibil să fi rulat cod Linux din epoca 2002, încetinind-o.
Zoom / Cipul de server Epyc de a doua generație de la AMD, este posibil să fi rulat cod Linux din epoca 2002, încetinind-o.

Getty Images

AMD a venit Un drum lung din 2002dar kernel-ul Linux încă tratează Threadripper-urile moderne ca sistemele din era Athlon – cel puțin într-un aspect care poate cauza decalaj.

Inginerul AMD Prateek Nayak recent Trimiteți un patch driverelor inactive ale procesorului Linux Acest lucru ar „ocoli așteptarea falsă pentru procesoarele bazate pe microarhitectura Zen”. Când suportul ACPI a fost adăugat la nucleul Linux în 2002 – scris de Andy Grover, de Linus Torvalds – a inclus un „model de așteptare fals”. Practic, sistemul citește datele fără alt scop decât să întârzie următoarea instrucțiune până când CPU oprește complet comanda STPCLK#. Acest lucru a permis unele economii de energie și compatibilitate în primele zile ale ACPI, când unele cipuri nu mergeau inactiv atunci când ne așteptam.

Dar cipurile AMD de astăzi bazate pe Zen nu au nevoie de această soluție și, așa cum a scris Nayak, îi rănește, cel puțin în anumite sarcini de lucru pe Linux. Testarea cu eșantionarea bazată pe instrucțiuni (IBS) arată că „o cantitate semnificativă de timp este petrecută în procesul inactiv, care este calculat incorect ca reședință în statul C”. Procesorul, văzând toată această fantomă de joasă tensiune funcționează, poate împinge într-o stare C mai profundă și mai lentă, ceea ce face ca procesorul să dureze mai mult pentru a se „trezi”, mai ales în joburile care necesită multă comutare între stările ocupat și inactiv.

READ  Scurgerea dezvăluie că telefonul Pixel 8a primește actualizări timp de 7 ani

Nayak a efectuat testele în tbanc Pe un Zen3 cu dublu soclu împotriva unui nucleu Linux, un nucleu cu o stare C2 complet dezactivată și un nucleu cu un proces de așteptare inactiv depanat. Versiunea sa corectată a înregistrat o creștere cu 1.390% a debitului minim MB/s și o creștere cu 51% a mediei MB/s pe nucleu, adesea doar puțin mai puțin decât dezactivarea completă a C2.

Sistemele Intel au evitat blestemul moștenit AMD, deoarece au folosit un sistem bazat pe MWAIT de cel puțin un deceniu, Potrivit blogului Phoronix. Aceasta a dus la Remediere rapidă oferită de Dave Hansen de la Intel. Soluția sa a fost să limiteze „așteptarea falsă” la sistemele Intel, deoarece nu ar afecta „sistemele la distanță Intel moderne” și să adauge comentarii la unitățile inactive din nucleu care să explice ce se întâmplă – și să încurajeze pe cei care citesc să „se gândească la mutarea sistemului la un mecanism’ Mai recent inactiv.

Dacă o remediere rapidă pentru a elimina sau a restricționa „așteptarea fantomă” este trimisă în această săptămână, probabil că va face nucleul Linux 6.0, care Torvalds așteaptă livrarea săptămâna viitoare.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *