AMD K10 TLB-hiba explained!

Úgy gondolom, hogy az AMD megérdemli, hogy szóljunk pár jó szót az érdekében azokban az időkben, amikor úgymond még az ág is húzza őket. A K10 megjelenése után megjelentek a neten a kárörvendő kórokozók, akik mindenféle háttérismeret nélkül ócsárolják a céget, belekapaszkodnak mindenféle kis negatívumba, és megpróbálják lehordani az AMD-t mindennek, aminek csak lehetséges, persze negatív értelemben.

A Phenom lassú, a Phenom sokat fogyaszt, a Phenom bugos, a Phenom blabla, más sem kell az AMD-nek, minthogy ezekben az időkben amikor a cég önmagával is küzd, még további hátráltató "elemek" lépjenek a színre.

A Phenom teljesítményével és fogyasztásával a Prohardveren egy cikk keretein belül foglalkozok, viszont a "rettegett" TLB-hibával kapcsolatos álláspontomat itt kívánom kifejteni. A PH!-s cikkben szándékosan nem esik szó a TLB-hibáról, hamarosan kiderül, hogy miért nem.

Szóval, mit is hallani mostanában? Arról hallani, hogy a Phenom/Opteron bugos, és fagy. A hiba kijavítható, de cserébe a teljesítmény drasztikusan lecsökken. Mi igaz ebből? Nos, az igaz, hogy a prociban van egy ilyen hiba, és az is, hogy a javítás után csökken a teljesítmény. De ez a hiba csak egy a sok közül, amit éppenséggel felkapott a sajtó, mert gondolom vkinek érdekében állt, hogy felkapja. A TLB-hibán kívül a K10-ben még van egy csomó dokumentált hiba, de ez nem csak a K10-re igaz, hanem az összes processzorra, éppenséggel a Core 2-nek is volt egy TLB-hibája (meg még több másik), de azt az Intel egy BIOS-frissítéssel orvosolta, és csak a nagy kuss maradt utána a tér/idő kontinuumban. Ezeket a hibákat általában laboratóriumi körülmények között tudják reprodukálni, amikor direkt arra hajtanak, hogy a hiba előbújjon, merthogy egy ilyen hibát nem egyszerű reprodukálni.

Az én meglátásom szerint ez annak köszönhető, hogy a K10-et felfokozott elvárások fogadták, az AMD anyagilag mélyponton van, és azt vártuk, hogy a K10 majd kihúzza őket a csávából, de ehelyett tovább csökkent a részvényeik árfolyama, igaz ez másnak köszönhető (gyártástechnológiai átállás lassúsága, teljesítményben versenyképes termékek hiánya, stb), és ha már fexenek a földön és szar nekik, akkor ez a kis rúgás már nem fog annyira fájni. Nos, de fáj. Térjünk a lényegre. A dolgokat próbálom minél egyszerűbben elmagyarázni, hogy még egy laikus is megértse.

Mi az a TLB? A translation lookaside buffer rövidítése. Mire jó ez a TLB? Röviden egy olyan gyorsítótár (puffer), amiben a virtuális memóriacímekhez tartozó fizikai memóriacímek tárolódnak.

Amikor a processzor egy memóriaolvasást vagy memóriaírást kísérel meg (load vagy store), először a logikai (virtuális) memóriacímhez tartozó fizikai memóriacímet kell, hogy kikalkulálja, ahol a számára szükséges adat található (vagy ahova írni akar). Hogy könnyebben érthető legyen, a számítógépben van mondjuk 1 GB RAM, de az oprendszer 32 bitnyi, azaz 4 GB-nyi (virtuális) memóriát tud megcímezni (fizikai+pagefile+vga mem+stb). Mivel nem azonos a két tárterület nagysága, címátfordításra van szükség. Itt egy kép, ami segít megérteni a dolgot.

A memóriaelérés során a proci kénytelen lefordítani a virtuális címet fizikai címre, hiszen csak a fizikai memóriába/ból tud írni/olvasni (vannak esetek, mint pl. megtelik a memória, és swappelni kell, amivel most nem foglalkozok). Mindez azt jelenti, hogy egy egyszerű memóriaírási/olvasási művelet egy második adat lekérését is magával fogja vonni, a processzor a page table-ből kiolvassa, hogy x virtuális címhez melyik fizikai memóriacím tartozik, vagyis egy olvasás vagy írás egyetlen műveletnek tűnik, mégis két memórialekérésre van szükség hozzá: be kell hívni a page table adott bejegyzését, és be kell írni/ki kell olvasni az adatot a memóriából.

Ez a módszer persze baromi lassú, mert a memória elérése mindig is lassabb, mint a gyorsítótáraké, és itt lép a színre a TLB. A TLB-ben eltárolódik az utolsó x darab címfordítás eredménye, tehát legközelebb, amikor a memóriából/ba olvasunk/írunk, tehát egy címfordításra van szükség, a processzor először a TLB-ben néz körül. Ha korábban már megtörtént ennek a virtuális címnek az átfordítása, akkor a proci egyszerűen kiolvassa a TLB-ből a címet (a cache elérése 3-10-20 ns szemben a K10 random memóriaelérésének 100+ ns-ával), és kiolvassa/beírja oda az adatot.

A K10 processzorban ezzel kapcsolatban a következő a probléma, ez az AMD leírása, megpróbáltam érthetően megfogalmazni (kb):

"Elképzelhető, hogy az egyik mag másodszintű gyorsítótárjának (L2 cache) TLB-jében az accessed vagy dirty* bitek átállítása 0-ról 1-re nem elemi (atomic**) művelet. Amíg az L2-ben a bejegyzések felülírása folyik probléma léphet fel, létrejöhet egy pici időintervallum, amikor egy másik cache-művelet az L3-at módosítja (de közben az L2-es TLB móka még nem fejeződött be). Ha ebben az időablakban mégegy cache-hozzáférés befut (4magos a proci), a processzor nem fogja beállítani az accessed vagy dirty biteket, és korrupt adatok jönnek létre."

Ez egy egyszerű cache-koherencia probléma.
Vegyük pl., hogy CPU1 egy másik mag által frissítés alatt álló laptábla bejegyzéshez (PTE) akar hozzáférni, ennek eredménye, hogy a CPU1 azt hiszi erről az adatról, hogy friss és illatos, felhasználható (tehát nem éppen frissül egy másik mag által és nem is dirty). A CPU2 befejezi a PTE frissítését, ennek az lesz az eredménye, hogy a két procinak most két különböző adat van a kezében (L2 cache), ugyanarról a PTE-ről, de erről egyikőjük sem tud. A CPU3 és CPU4 szintén a CPU2 adataival dolgozik, mert az a legfrissebb. Amikor a CPU1 a hibás PTE alapján elkezd dolgozni az L3-ban (ami mint tudjuk közös), és ehhez a másik három CPU hozzá akar férni, akkor bizony rossz adatokkal találkoznak. Ugyanez lejátszódhat fordítva is: CPU2/CPU3/CPU4 dolgozik az L3-ban, amihez a CPU1 hozzá akar férni, bumm.

A BIOS-os patch nemtom, hogy pontosan mit csinál, de az biztos, hogy szépen belassítja a gépet. El lehet képzelni, egy nagy adatmozgatással járó művelethez TLB nélkül mag/cache-enként kb. kétszer annyi memóriahozzáférésre van szükség (a page table ugye), még szép, hogy belassul a gép. Ha jóltom, akkor Linuxhoz kiadtak egy patchet, ami szükségtelenné teszi a BIOS-patch használatát, mindössze annyit csináltak, hogy emulálják a dirty-biteket.

A lényeg pedig: a hiba gyakorlatilag előidézhetetlen, éppen ez okozta az AMD-nek a problémát, ugyanis ahhoz, hogy ki tudják javítani a hibát, először reprodukálni kell, és ez állítólag hónapokba telt nekik.
Summa summarum egyáltalán nem kell félni attól, hogy ez a hiba előjön egy otthon használatos Phenomon.
Persze az Opteronok esetében ez más tészta, hiszen egy szerverprocival szemben sokkal magasabb követelményeket támasztanak, az AMD nem is szállítja a harmadik generációs K10-alapú Opteront mindaddig, amíg a hibát ki nem javították. Jól is teszik, inkább legyenek lassabbak a konkurenciánál, minthogy hibás procikat adjanak el, amire hivatkozva később visszamondhatják a megrendeléseket.

A lényeg ennyi lett volna.

*: ezek olyan bitek a cache-ben vagy a virtuális memóriában, amiket a proci már módosított, de még nem lettek visszaírva a háttértárolóra (RAM, vinyó)
**: több memóriaműveletet (read-modify-write) elvégző nem megszakítható (elemeire nem bontható) utasítás