Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Současné vývojové jádro je 4.11-rc8; finální verze 4.11 nebyla vydána 23. dubna, jak se očekávalo. Linus se raději rozhodl vydat ještě jeden prepatch. „Původně jsem zamýšlel 4.11 vydat dnes, ale přestože minulý týden nedošlo k *mnoha* změnám, pár jich bylo dost otravných, takže místo toho tu máme ještě jedno rc vydání. Dostal jsem opravy problémů, které se objevily, takže jsem mohl 4.11 vydat v tomto stavu, ale nebylo by to v pořádku.“
Seznam regresí z 21. dubna ukazuje deset známých problémů v jádře 4.11.
Stabilní aktualizace: 4.10.12, 4.9.24 a 4.4.63 byly vydány 21. dubna. O den později následovala 3.18.50.
Stabilní verze 4.10.13, 4.9.25 a 4.4.64 byly v době psaní tohoto článku v procesu revidování, vydány byly 27. dubna.
Subsystém vícefrontové blokové vrstvy, který byl představen v roce 2013, byl nezbytným krokem k tomu, aby jádro škálovalo s nejrychlejšími paměťovými zařízeními na velkých systémech. Implementace v současných jádrech je ale neúplná, postrádá totiž plánovač I/O navržený tak, aby pracoval s vícefrontovými zařízeními. Mezera by měla být vyplněna ve vývojovém cyklu 4.12, v němž jádro dostane ne jeden, ale hned dva vícefrontové plánovače I/O.
Absence plánovače I/O může v kódu pro více front vypadat jako zásadní vada, ale pravdou je, že potřeba plánovače nebyla od počátku jasně patrná. High-end disky jsou většinou SSD, jež netrpí problémy se zpožděním kvůli rotaci, takže nejsou tak citlivé na pořadí operací. Ovšem ukazuje se, že plánování I/O má smysl i v případě těch nejrychlejších zařízení – plánovač může spojovat sousedící požadavky, a tak snížit celkový počet operací, a upřednostňovat některé operace před jinými. Takže zájem o přidání plánování I/O vícefrontových zařízení je tu už nějaký čas, ale dosud chyběl kód.
Řešení se přiblížilo se začleňovacím oknem 4.11, kdy bloková vrstva získala podporu plánování I/O vícefrontových zařízení. Plánovač I/O deadline přešel na tento mechanismus jako důkaz proveditelnosti, ale nikdo jej nevnímal jako skutečné řešení do budoucna.
Po přidání plánování I/O byl prvním zamýšleným využitím plánovač BFQ (Budget Fair Queuing), na němž se pracuje už roky. Každému procesu přiděluje rozpočet I/O, což v kombinaci s několika heuristikami vede k údajně mnohem lepší odezvě I/O, zvláště na pomalejších zařízeních. Uživatelé s rotačními úložišti mají z BFQ prospěch, existují však výhody i při použití pomalejších SSD zařízení. V důsledku je tu značný zájem o použití BFQ například v mobilních zařízeních.
Myšlenka, že BFQ je lepší než plánovač CFQ, který se nachází v hlavních jádrech, není nijak zvlášť kontroverzní, ale začlenit BFQ byl i tak dlouhý proces. Jednou z posledních překážek bylo, že šlo o tradiční plánovač I/O spíše než vícefrontový plánovač. Vývojáři subsystému blokové vrstvy mají dlouhodobý cíl přejít u všech ovladačů na vícefrontový model a začlenění obyčejného (tedy ne vícefrontového) plánovače I/O se nejevilo jako krok tímto směrem.
Vývojář BFQ Paolo Valente v posledních několika měsících pracoval na převedení kódu do vícefrontového rozhraní. Známé problémy s jeho prací byly vyřešeny a správce blokového subsystému, Jens Axboe, souhlasil se začleněním do vydání 4.12. Pokud všechno půjde podle plánu, bude dlouhé čekání na plánovač BFQ u konce.
Zajímavé je, že BFQ nebude jediným plánovačem vícefrontového I/O, který se v cyklu 4.12 dostane do upstreamu. Ten druhý, vyvinutý v mnohem kratším čase, by totiž měl být také začleněn. Člověk by se mohl divit, k čemu je potřeba druhý plánovač, obzvláště když vývojáři kladou důraz na obecná řešení, která mohou pokrýt širokou škálu použití. Ovšem zdá se, že vskutku existuje rozumný důvod pro začlenění druhého vícefrontového plánovače.
BFQ je složitý plánovač navržený tak, aby poskytoval dobrou interaktivní odezvu, zvláště na pomalejších systémech. Má relativně vysokou režii pro dílčí operace, což je opodstatněné, když I/O operace samotné jsou pomalé a drahé. Tato složitost ale nemusí dávat smysl v situacích, kdy jsou I/O operace levné a hlavním problémem je propustnost. Při pracovní zátěži serveru používajícího SSD může být lepší používat jednodušší plánovač, který umožňuje slučování požadavků a možná i jednoduchá pravidla, většinu času se však neplete do cesty.
Plánovač I/O Kyber, kterým přispěl Omar Sandoval, by mohl být přesně tím potřebným plánovačem. Je určen pro rychlá vícefrontová zařízení a postrádá většinu složitosti plánovače BFQ. Nemá ani tisíc řádek kódu. Jeho pravidla, i když jednoduchá, se jeví jako zajímavá ozvěna práce na bufferbloatu, kterou se povedlo udělat v části jádra, která má na starosti síťování.
I/O požadavky procházející skrze Kyber jsou rozděleny do dvou primárních front, jedné pro synchronní a druhé pro asynchronní požadavky – jinými slovy, jedné pro čtení a druhé pro zápisy. Proces, který žádá o čtení, obvykle není schopen pokračovat, dokud není příslušnému požadavku vyhověno a data nejsou k dispozici, tudíž tyto požadavky jsou vnímány jako synchronní. Naopak operace zápisu může být dokončena někdy později, přičemž žádající proces většinou nezajímá, kdy k zápisu skutečně dojde. Takže je běžné upřednostňovat čtení před zápisy, nikoliv však do té míry, že by došlo k vyhladovění zápisů.
Klíčem k algoritmu Kyber je to, že počet operací (čtení i zápisu) odeslaných do odbavovacích front (které směřují operace přímo zařízení) je striktně omezen tak, že udržuje tyto fronty relativně krátké. Pokud jsou odbavovací fronty krátké, pak je množství času, který uplyne během čekání požadavku ve frontě (latence dílčího požadavku), poměrně malé. To zajišťuje rychlé dokončení požadavků s vyšší prioritou.
Plánovač reguluje skutečný počet požadavků vpuštěných do odbavovacích front podle měření doby nutné ke splnění jednotlivých požadavků a úpravou limitů k dosažení požadovaných latencí. K dosažení cílových latencí slouží správci systému dva atributy s výchozími hodnotami 2 ms pro čtení a 10 ms pro zápis. Jako vždy bude při nastavování těchto hodnot docházet ke kompromisům. Příliš nízké hodnoty zajistí nízké latence, ovšem za cenu méně příležitostí ke sloučení požadavků, což zhorší propustnost.
Také Kyber byl přijat do začleňovacího okna 4.12. Takže pokud půjde vše podle plánu, bude mít jádro 4.12 dvě nové možnosti plánování I/O ve vícefrontových zařízeních. Uživatelé, kteří se zabývají interaktivní odezvou a možná pracují s pomalejšími zařízeními, se pravděpodobně přikloní k BFQ, zatímco servery, na kterých poběží úlohy citlivé na propustnost, budou pravděpodobněji používat Kyber. Každopádně se podařilo zaplnit významnou mezeru v subsystému vícefrontového blokového I/O, čímž se otevírá cesta k případnému přechodu všech jaderných blokových ovladačů na vícefrontové API.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: