Linus doladil Intel Linear Address Masking a hned ho zařadil do Linuxu 6.4
Kód pro podporu použití techniky Linear Address Masking u Intelu (podrobněji v popisu LAM z roku 2021) se vývojáři procesorového gigantu snažili dostat do Linuxu už před časem, ale v rámci verze 6.2 je Linus vypoklonkoval pro technickou (ne)kvalitu kódu.
Vývojáři na podpoře LAM dále pracovali a dostali celou věc do stavu, kdy se Linus sám rozhodl doladit zbývající drobnosti a kód zaslat k začlenění do vývojové větve budoucího jádra 6.4 (aktuálně jsme ve fázi verze 6.4-rc2).
Mezi věcmi, které Linus opravoval, bylo například oddělení ryze 64bit kódu do samostatného hlavičkového souboru, aby nebyl smíchán s generickým sdíleným kódem a věc alespoň vypadala tak, že může běžet na 32bit systému.
Hibernace a STD pro RISC-V
Podpora režimů Hibernation a Suspend-To-Disk na platformě RISC-V bude v jádru 6.4. Vývoj trvající několik měsíců je završen, kód prošel kontrolou a v jádru tak bude možné používat volby CONFIG_HIBERNATION / CONFIG_ARCH_HIBERNATION_HEADER / CONFIG_ARCH_HIBERNATION_POSSIBLE. Podobně je zprovozněn též režim uspání na disk, vše pak doprovází příslušný low level kód a další doprovodné funkce.
Testy ověřily funkčnost na platformě StarFive VF2 SBC a také QEMU za použití raw diskového formátu. Podpora ACPI ale stále chybí, tu čekejme až s některou budoucí verzí jádra po 6.4.
Potřebný binární blob pro iGPU Intel Meteor Lake v i915
Jelikož už i Intel potřebuje k plnohodnotnému běhu svých GPU binární uzavřený kód, sluší se hlásit, že do jádra 6.4 míří příslušně aktualizovaný balík GuC verze 70.6.6, který přináší podporu příští generace CPU Intel Meteor Lake (připomeňme, že její doménou budou notebooky, nikoli desktopy).
Věc již leží v příslušné větvi jaderného Gitu, avšak vedle samotného stroje platformy Meteor Lake bude i s jádrem Linux 6.4 potřeba k provozu ruční aktivace podpory pomocí přepínače i915.force_probe.
Phoronix dále srovnává, že Intel zveřejňuje tyto balíky často s velkým předstihem oproti reálnému uvedení na trh, zatímco AMD obvykle jen pár dnů před dostupností nových GPU na trhu. Nejhůře je na tom samozřejmě Nvidia, která sice drží kvalitní podporu i nových produktů v rámci vlastních uzavřených ovladačů, ale podepsané firmwary pro nouveau vydává často s velkým zpožděním mnoha měsíců (a dodejme: leckdy i celých let).
Linux 6.5 prozrazuje L4 cache v Meteor Lake
Když už jsme u Meteoru, tak rovnou přejděme od finišovaného vývoje Linuxu 6.4 k rozbíhajícímu se vývoji Linuxu 6.5. Patche pro Meteor Lake, které se neobjeví v produkčním jádru dříve než právě s verzí 6.5 totiž (definitivně) prozradily zajímavost architektury Meteor Lake: ponese L4 cache. Ono se totiž ukázalo, že další vrstva velké/pomalejší cache totiž má často poměrně slušný benefit u některých tupů úloh, a to u V-cache procesorů jako Ryzen 5800X3D či sedmičkových modelů.
Nemusíme však ani ke konkurenci, kdy v éře Broadwellu (první 14nm procesory Intel v roce 2015) existovaly BGA kousky jako Core i7–5775C s přídavnou eDRAM, která značně zvyšovala výkon již tak solidního iGPU (podobně existovala doba, kdy Athlony měly k dispozici některé varianty čipsetů nesoucí 128MB eDRAM s podobně kladným efektem na výkon iGPU v čipsetu, ale to už příliš odbočuji).
Zkrátka procesory Intel generace Meteor Lake ponesou i L4 cache, což prokazují patche pro ovladač i915. A to je hodně dobrá zpráva pro všechny, kterým stačí výkon iGPU a nechtějí kvůli troše nenáročného hraní kupovat nejlevnější smysluplnou grafickou kartu (což dnes znamená investici minimálně 5–6 tisíc Kč). Třeba Intel zase o kousek stáhen náskok, který má v iGPU konkurenční AMD.
- Pozn: Meteor Lake jsme se věnovali už i v dřívějším shrnutí novinek, chystaných pro Linux 6.4.
Vylepšený běh hybridních CPU Intel na Linuxu 6.5
Jako s každou verzí jádra za poslední rok a půl od uvedení Alder Lake, můžeme i pro Linux 6.5 říci, že vývojáři Intelu zase o kousek vylepší flexibilitu běhu na hybridních CPU architekturách. Tentokrát půjde (opět) o ladění onoho kódu řídícího rozhazování úloh tak, aby se Linux zase o kus lépe vyhýbal situacím, kdy budou úlohy zbytečně migrovány v rámci SMT domén.
Připomeňme, že Intel se v nastavení pro přehazování úloh v rámci HT jader vrtal už loni v srpnu a také v listopadu. I tentokrát se bavíme o situaci CPU jader běžících s Turbo Boost Max 3.0 a asym_packing, kde je tendence přiřazovat úlohy jádrům s vyšší maximální frekvencí, ale současně dojde k uměle přiřazené hodnotě nižší priority výše číslovanému dvojčeti v SMT u daného CPU jádra, aby byla jistota, že se použije jako poslední – v tomto se vrtaly už některé výše zmíněné dřívější patche a nyní se již zjistilo, že takové přenastavení priorit vede ke zbytečným migracím v rámci SMT domén, kde CPU jádro hybridního procesoru má tendenci brát úlohy jádrům s vyšší prioritou, když u nich jejich SMT dvojče vytíženo. Celý balík úprav ladících chování scheduleru na hybridních CPU, který Intel ladí poslední měsíce a měsíce, je konečně zralý, aby zamířil do jádra a s Linuxem 6.5 tedy můžeme čekat nějaké viditelné pozitivní změny vzešlé z této čtvrté verze patchů.
V příslušné vývojové větvi jádra se pak už rodí i první patche pro Meteor Lake, který navíc bude architektonicky realizován tak, že jádra s rozličnými maximálními frekvencemi budou na více křemíkových die (u Alderu a Raptoru jde vždy o jednu stejnou die). Tohle bude ještě zajímavé.
ČLÁNKY DO MAILU