Az AMD mérnökei az utóbbi időben egy olyan, a Linux kernel (Linux kernel) memóriakezelését érintő alapvető fejlesztésen dolgoznak, amely „pghot” néven fut, és egy forró lapok (hot page) követésére és előléptetésére szolgáló alrendszert (hot-page tracking and promotion subsystem) vezetne be. A javaslat különösen ott ígér komoly előnyt, ahol modern AMD EPYC szerverekben többféle memóriaszint (memory tiers) él egymás mellett, például CXL-lel (Compute Express Link) bővített konfigurációkban, és a rendszernek folyamatosan döntenie kell arról, mely adatok kerüljenek a gyorsabb, „felsőbb” memóriába, és melyek maradjanak a lassabb rétegekben.

A legfrissebb fejlemény, hogy Bharata Rao, az AMD egyik mérnöke közzétette a legújabb, véleményezésre szánt (request for comments, RFC) patchcsomagot, amely a pghot koncepcióját valósítaná meg a Linux kernelben (Linux kernel). A cél egy olyan egységes infrastruktúra, amely több forrásból is képes összegyűjteni a „forró” memórialapok azonosításához szükséges jelzéseket, központi helyre tereli a lapok előléptetésének (promotion) döntési logikáját, és egyben rendet tesz abban is, hogy a kernel különböző részei jelenleg egymástól függetlenül követik a lapeléréseket (page access tracking).

A pghot mögötti alapgondolat a mai, heterogén memóriarendszerek miatt vált igazán fontossá. A klasszikus szervereknél sokáig viszonylag „egyszintű” volt a memória: a DRAM volt a fő munkaterület, a háttértár pedig teljesen más kategóriát képviselt. A CXL és a több memóriaszintű felépítések terjedésével viszont megjelentek olyan konfigurációk, ahol a gépben egyszerre van jelen gyors, alacsony késleltetésű memória és nagyobb, de lassabb, esetleg megosztott vagy bővítőn érkező kapacitás. Ilyenkor a teljesítmény szempontjából kritikus kérdés, hogy a gyakran használt adatok valóban a gyorsabb rétegben legyenek-e, és hogy a kernel milyen gyorsan és mennyire „okosan” tud alkalmazkodni a terhelés változásaihoz.

A mostani leírás szerint a pghot működésének részleteit a patchcsomag kísérőlevelében foglalják össze, a gyakorlati eredmények pedig biztatóak. A tesztek egy AMD EPYC Zen 5 szerveren futottak, ahol két CPU-s NUMA csomópont (NUMA node) mellett egy CXL csomópont is jelen volt. A mérések alapján időmegtakarítás mutatkozott a benchmarkokban, mégpedig kétféle helyzetben is: egyrészt olyan szcenáriókban, ahol a rendszer főként lapok előléptetését vizsgálta, másrészt akkor is, amikor a leggyorsabb memóriaszint túl volt foglalva (over-committed), és emiatt a rendszernek egyszerre kellett előléptetést és visszasorolást (demotion) is végeznie.

A téma jelentőségét az adja, hogy a „forró lapok” kezelése nem pusztán egy újabb mikroszkopikus optimalizáció: több memóriaszint mellett ez a fajta döntéshozatal közvetlenül befolyásolja, mennyire lesz kiszámítható a késleltetés, mennyire stabil a throughput, és mennyire tudja a kernel elkerülni azt, hogy a gyakran használt adatok „rossz helyen” ragadjanak. Ha a pghot valóban képes egységesíteni a jelenleg széttagolt lapelérés-követési megoldásokat, az hosszabb távon nemcsak az EPYC + CXL környezetekben, hanem általában a heterogén memóriát használó Linux rendszereken is érezhető előrelépést hozhat.

Az AMD egyik mérnöke, Bharata Rao közzétette a legfrissebb, véleményezésre szánt (RFC, request for comments) patch-sorozatát, amely a pghot koncepciót valósítaná meg a Linux kernelben (Linux kernel). A pghot célja egy olyan „forró lap” (hot page) követési infrastruktúra létrehozása, amely egységes keretbe tereli a több forrásból érkező forró-lap detektálást, központosítja a forró lapok előléptetésének (promotion) döntési logikáját, és összefogja azokat a jelenleg külön utakon működő megoldásokat, amelyek a Linuxban egymástól függetlenül figyelik a lapeléréseket.

A patch-ek kísérőlevelében Rao röviden azt is összefoglalja, hogyan működik a pghot. A rendszer a lapok elérési gyakoriságát és az utolsó hozzáférés idejét követi, és egy „precíziós” módban azt is rögzíti, hogy az adott hozzáférés melyik NUMA csomópontról (NUMA node) érkezett, vagyis eltárolja az elérő csomópont azonosítóját (NID). A „forróságot” leíró paramétereket PFN-enként (PFN, page frame number) tárolja, mégpedig a meglévő mem_section adatszerkezeten belül vezetett hotness rekordban.

Alapértelmezett módban mindehhez mindössze 1 bájt (u8) áll rendelkezésre: ebből 5 bit jut az idő reprezentálására, és egy „vödrözéses” (bucketing) séma segítségével a teljes elérési időtartomány nagyjából 4 másodpercig ábrázolható, ha a rendszeridő-alap HZ=1000. Ebben a módban a pghot a 0-ás NID-et tekinti alapértelmezett „felső szintű” (toptier) célpontnak az előléptetéshez, amit hangolható paraméterekkel (tunable) később módosítani lehet. Precíziós módban már 4 bájtos (u32) rekordot használ: itt 14 bit jut az idő tárolására, ami HZ=1000 mellett nagyjából 16 másodpercnyi tartományt fed le.

A pghot a lapokat konfigurálható küszöbértékek alapján sorolja „forró” kategóriába. Az így forrónak minősített lapok egy „ready” bittel megjelölve migrációra késznek számítanak; mindkét módban a hotness rekord legmagasabb helyiértékű bitje (MSB) tölti be ezt a szerepet. A tényleges áthelyezést a rendszer úgy végzi, hogy az alsóbb memóriaszintekhez (lower-tier) tartozó csomópontokon futó kmigrated szálak időnként végigpásztázzák az adott csomópont PFN-jeit, és ahol a migrációra kész jelzés aktív, ott kötegelt migrációt (batched migrations) hajtanak végre. A pásztázások közötti időköz és a kötegelés mértéke szintén hangolható.

A fejlesztés a Linux kernel levelezőlistáján érhető el: a pghot patch-ek jelenleg RFC státuszban vannak, vagyis a cél egyelőre a szakmai visszajelzések begyűjtése és a megközelítés finomítása, mielőtt bármilyen éles integráció szóba kerülne.

A gyakorlati eredmények szempontjából a lényeg az, hogy a pghot nem pusztán egy újabb, elszigetelt optimalizációt ígér, hanem egy olyan közös infrastruktúrát, amely a heterogén memóriájú rendszerekben – különösen több NUMA csomóponttal és CXL-lel (Compute Express Link) kiegészített konfigurációkban – segíthet kiszámíthatóbban kezelni, mely adatok kerüljenek a gyorsabb memóriaszintre, és melyek szoruljanak vissza lassabb rétegekbe. A közölt tesztek alapján egy AMD EPYC Zen 5 szerveren, két CPU-s NUMA csomóponttal és egy CXL csomóponttal mérhető időmegtakarítás jelent meg a benchmarkokban: egyrészt olyan helyzetekben, ahol főként lapok előléptetése történt, másrészt akkor is, amikor a felső memóriaszint túl volt foglalva (over-committed), és emiatt a rendszernek egyszerre kellett előléptetést és visszasorolást (demotion) végeznie.

Érdemes hozzátenni, hogy a „forró lapok” követése a Linuxban régóta létező igény, de a modern, több memóriaszintet kombináló gépeknél (klasszikus DRAM + perzisztens vagy bővítő memóriák, illetve CXL-es memóriabővítők) a tét nagyobb: ha a kernel rosszul ítéli meg, mi számít valóban „forrónak”, akkor a gyakran használt adatok könnyen rossz memóriaszinten ragadhatnak, ami nemcsak átlagos lassulást, hanem kellemetlen késleltetési tüskéket is okozhat. Egy egységesített, több forrás jelzéseit összehangoló pghot-szerű réteg ezért hosszabb távon a teljes rendszer viselkedését teheti stabilabbá: nemcsak az EPYC + CXL jellegű csúcskonfigurációkban, hanem általában minden olyan Linuxos környezetben, ahol a memóriahierarchia már nem „egyszintű” történet.