Az Ubuntu 26.04 LTS célja, hogy jelentősen javítsa az NVIDIA grafikus kártyák teljesítményét a GNOME Wayland munkamenetében. A fejlesztések egy része akár a GNOME 50 részeként is bekerülhet, de előfordulhat, hogy az Ubuntu saját javításokat visz be a rendszerbe a Wayland teljesítményének optimalizálására. Ez különösen fontos, mivel az Ubuntu 26.04 LTS már kizárólag Wayland-et használ a GNOME asztali környezet alatt, szemben a 24.04-es kiadással.

Az EXT4 fájlrendszer új fejlesztései lehetővé teszik, hogy a blokkméret meghaladja a kernel oldalméretét, így a Linux tárolórendszerek teljesítménye tovább javulhat. A változtatás követi a Btrfs és XFS fájlrendszerek hasonló fejlesztéseit, amelyek már korábban bevezették a nagyobb blokkméretek támogatását. A Huawei mérnöke, Baokun Li szombaton küldte ki a patch-sorozatot, amely az EXT4 nagy blokkméret (Large Block Size, LBS) támogatását valósítja meg.

A Linux 6.18 kernel új patch-et hoz azoknak, akik a közel egy évtizedes AMD Bulldozer processzorokat használják, és szeretnék kihasználni a Linux X86_NATIVE_CPU build opcióját a teljesítmény növelésére az adott processzor/ISA képességeire optimalizált kernel fordításával.

A Linux kernel fejlesztői folyamatosan dolgoznak azon, hogy a többmagos rendszerek teljesítményét és skálázhatóságát javítsák. A közelgő 6.18-as verzió egyik ígéretes újdonsága a Sheaves, egy választható (opt-in), per-CPU, tömbalapú gyorsítótár-réteg (array-based caching layer) a SLUB memória-allokátorhoz. A Google által karbantartott javításcsomag már bekerült a slab/for-next Git ágba, így jó eséllyel ott lesz a 6.18-as kernel összeolvasztási ablakában.

Az AMD régebbi GFX6 és GFX7 architektúrájú grafikus processzorai mostantól ellenőrzött Vulkan 1.3 támogatást kapnak a Linux rendszerekhez készült nyílt forráskódú Mesa RADV driver által, mely fejlesztést a Khronos Group is elismert.

A Valve mérnöke, Samuel Pitoiset jelentős teljesítménynövekedést ért el a Mesa RADV driver számára az AMD FidelityFX Super Resolution 2 (FSR2) használatakor. Ezzel a frissítéssel a nyílt forráskódú RADV driver lényegesen hatékonyabbá vált, és közelebb került az AMD hivatalos Vulkan driverének teljesítményéhez.

Az NVIDIA legújabb, nyílt forráskódú Linux kernelmeghajtója mostanra olyan fejlett, hogy a teljesítménye már megegyezik a zárt forráskódú meghajtóval. A cikk bemutatja az új fejlesztéseket, amelyek a Turing és újabb GPU-k esetében a nyílt forráskódú modult alapértelmezetté teszik, miközben továbbra is biztosítják a teljesítményt és az energiahatékonyságot.

2002 óta, amikor a kernel ACPI-támogatással bővült, egy felesleges várakozási - „dummy wait” művelet került be a kernelbe. Történt ez mindazért, mert akkoriban néhány chipkészletnél az STPCLK# nem volt időben érvényesítve a kernelben az üresjárat során. A dummy I/O olvasás késlelteti a további utasításfeldolgozást, amíg a CPU teljesen le nem áll. Az AMD egyik mérnöke azonban nemrégiben észrevette, hogy ezt a viselkedést a modern AMD Zen 3 hardvereken is alkalmazzák, és megállapította, hogy ez teljesítményproblémákhoz vezethet az terhelt és üresjárati fázisok között gyorsan váltó munkaterheléseknél, és különösen a nagyobb magszámú rendszerek, például a Ryzen Threadripper és EPYC platformok esetében.

K Prateek Nayak, az AMD mérnöke, kimutatta, hogy a hibás megoldása milyen jelentős hatással lehet a teljesítményre a modern hardverekre az AMD rendszereken. Az Intel CPU-k eközben nem használják ezt a kódutat a modern hardverekhez, így nem érinti őket ez a teljesítményvesztés. Az adott tesztben a minimum adatátviteli értékek 1390.52 százalékkal növekedtek és az átlagos adatátvitel is 50.85 százalékkal emelkedett.

Eredetileg az AMD egy javítást végzett itt, majd Dave Hansen, az Intel mérnöke tisztította és egyszerűsítette ezt a kódot. Ez utóbbi javítás egyszerűen nem alkalmazza ezt a "dummy wait" megoldást, kivéve a régebbi (Nehalem előtti) Intel rendszereket. Mostantól tehát az AMD rendszerek is kihagyják ezt a műveletet, amely a modern rendszereken ronthatja a teljesítményt. Mivel ez főként az leterhelt és az üresjárati állapotok között gyakran váltó munkaterhelésekre van hatással, valamint a nagyobb magszámú rendszereknél jobban észrevehető, az AMD EPYC szerver teljesítménye ezzel a javítással meglehetősen érdekes lehet, különösen a webszerver / adatbázis-munkaterhelések és más típusú gyors tesztek esetében.