Új Linux Zswap javítások látványos teljesítménynövekedést hoznak

enlightened Ez az oldal a közösségért készül. heart Kövess minket máshol is:  Linux Mint Magyar Közösség a Mastodon-on  Telegram csatorna – csak hírek  Beszélgessünk a Telegram – Linux csevegő csoport  Hírek olvasása RSS segítségével  Linux Mint Hivatalos Magyar Közösség a Facebook-on      Linux Mint Baráti Kör a Facebook-on
wink Ha hasznosnak találod, és szeretnéd, hogy folytatódjon, támogasd a munkát Ko-fi vagy Paypal segítségével. laugh

kami911 képe

Usama Arif Linux-fejlesztő két javítócsomagot tett közzé a Zswaphoz, amelyek célja a Zswap terhelés alatti kérésütközéseinek csökkentése. A zRAM-nél végzett hasonló munka nyomán most a Zswap kódját is úgy alakítják át, hogy kezelje azt a jelenlegi hiányosságot, miszerint a tárolási (store) és olvasási (load) műveletek egy per-CPU acomp kérést és mutexet osztanak meg. Ez a jelenlegi kezelés végül szűk keresztmetszetnek bizonyult, a két javítócsomag pedig segít csökkenteni a terhelés alatti ütközéseket.

Usama Arif a javítócsomag kísérőlevelében részletesebben is elmagyarázta:

„A tárolási és olvasási műveletek egy per-CPU acomp kérést és mutexet osztanak meg. Egy alacsony prioritású tárolási műveletet megszakíthatják közvetlenül azután, hogy a tömörítő elengedi a stream lockot, miközben még mindig nála van a zswap mutex. Ilyenkor az adott CPU-n egy magasabb prioritású olvasási művelet arra vár, hogy a tárolási művelet folytatódjon. Ez követi Sergey Senozhatsky zram sorozatának munkáját, ahol ugyanezért választották szét ezeket.

Az első javítócsomag külön kéréseket, várakozásokat és mutexeket ad a tömörítésnek és a visszafejtésnek, így az olvasások már nem várnak a tárolásokra, bár egymásra még mindig várhatnak. A második javítócsomag veremre (stackre) helyezett kéréssel végzi a visszafejtést, ha az algoritmus szinkron és nincs szükség külön kéréskörnyezetre; ez az összes, a fában lévő szoftveres tömörítőre igaz, így ezeknél az olvasásoknál nincs szükség zswap lockra. Az aszinkron algoritmusok megtartják a per-CPU kérést és mutexet. A szoftveres tömörítők esetében a sorozat ugyanannyi kérést foglal, mint korábban; minden per-CPU kontextus 72 bájttal nő, és az olvasási útvonal körülbelül 270 bájttal lesz mélyebb x86-64-en.”

A végeredmény különösen meggyőző:

Usama a javítócsomag-sorozatban így részletezte a méréseket:

„Az alábbi számok futásonként a leglassabb olvasást mutatják, 5 futás mediánjaként (min-max). Minden futás 12 másodpercig tart egy zstd VM-ben, lazy preemptionnel, vm.page-cluster=0 beállítással és swap-pel a /dev/ram0 eszközön. 1 vCPU mellett négy nice +10 worker lapozza ki a memóriát és olvassa vissza, miközben egy nice 0 feladat pörög. Egy nice -19 olvasó a saját bufferét lapozza ki, és méri, mennyi ideig tart minden egyes olvasás. 8 vCPU esetén 16 worker, 8 pörgő feladat és 8 olvasó fut.

Javítócsomag előtt (ms) Javítócsomaggal (ms)

1 vCPU 22,3 (21,6–22,6) 0,97 (0,72–1,4)

8 vCPU 314 (97–2542) 7,0 (5,0–98)

A 10 ms feletti olvasások száma 1 vCPU mellett futásonként 26–35-ről nullára esett, 8 vCPU mellett pedig 3–18-ról legfeljebb egyre. A benchmarkot és a tesztprogramokat egy LLM segítségével írtuk.”

Összességében nagyon ígéretes Zswap teljesítmény-fejlesztésről van szó, amelyet jelenleg a Linux kernel levelezőlistán vizsgálnak.