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.

