Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Pro hlavní řadu nevyšla žádná předverze; okno pro začleňování nového kódu do 2.6.24 zůstává otevřeno. Do hlavního repozitáře rychle proudí patche; nejzajímavější věci jsou představeny níže v textu.
Aktuální verze -mm stromu je 2.6.23-mm1. Nedávné změny: infrastruktura pro novou funkci správy napájení "kvalita služeb", několik aktualizací ext4 a patch s jadernými značkovači.
Aktuální stabilní jádro řady 2.6 je 2.6.23.1, vydané 12. října. Aktualizace obsahuje jedinou opravu problému s poškozením dat v ovladači sata_mv.
Starší jádra: 2.6.16.55 bylo vydáno 14. října s několika bezpečnostními opravami.
Ne každý je "dělač". Je důležité získávat zpětnou vazbu i od lidí, kteří jsou obyčejní uživatelé - nebo by chtěli být.
-Limit délky řádků je 80 znaků - nesmí být překročen. +Limit délky řádků je 80 znaků - pokud možno by neměl být překročen.
-- Alan Cox v 2.6.24 uvolňuje pravidla.
Začleňování nového kódu stále probíhá; doposud si do jádra našlo cestu asi 5600 patchů. Jako obvykle je seznam změn velmi dlouhý. Mezi ty zajímavější změny, kterých si všimnou i uživatelé, patří:
Důležité změny viditelné pro vývojáře jádra:
Síťová vrstva má novou funkci pro výpis MAC adres:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
char *print_mac(char *buf, const u8 *addr);
Buffer buf by měl být deklarován pomocí DECLARE_MAC_BUF(); výstup je vhodný pro formátování v printk() se "%s".
Zpětná volání slab konstruktoru se změnila na:
void (*ctor)(struct kmem_cache *cache, void *object);
Nepoužívaný parametr flags byl odstraněn a pořadí zbývajících dvou bylo obráceno, aby odpovídalo ostatním slab funkcím.
Několika utilitám blokové vrstvy se změnily prototypy. Asi nejpatrnější změnou je bio_endio() a příslušné zpětné volání bio_end_io_t:
void bio_endio(struct bio *bio, int error);
typedef void (bio_end_io_t) (struct bio *, int);
Tyto funkce teď pokaždé zkompletují celé BIO, takže byl odstraněn parametr size.
Dá se očekávat, že období pro začleňování do 2.6.24 potrvá ještě týden, takže než nastane stabilizační fáze, do hlavního stromu se určitě dostane ještě více změn.
Completely Fair Scheduler (CFS) byl začleněn v jádře 2.6.23. Nedostalo se však na skupinové plánování, s jehož pomocí funguje CFS algoritmus hierarchicky: procesy jsou rozděleny do skupin a v rámci každé skupiny jsou procesy navzájem férově plánovány. Na vyšší úrovni je každé skupině přidělen férový podíl procesoru. Seskupování procesů je velmi flexibilně prováděno v uživatelském prostoru; mechanismus kontrolních skupin (dříve "kontejnerů procesů") umožňuje klasifikaci procesů podle skoro jakýchkoliv pravidel.
Jedním z důvodů, proč se skupinové plánování nedostalo do 2.6.23, je skutečnost, že patch přidávající podporu pro kontrolní skupiny nebyl hotový. Vypadalo to, že se dostane do 2.6.24, ale v tuto chvíli se zdá, že je ještě příliš aktivně vyvíjen, aby mohl do hlavního jádra. Skupinové plánování však nečeká; do 2.6.24 už bylo zařazeno. Kvůli nepřítomnosti podpory kontrolních skupin však nebude mechanismus skupinového plánování k dispozici. Za posledních několik měsíců se ale u skupinového plánování vyvinula nová funkce, která umožní použití i bez kontrolních skupin, a která implementuje způsob, jak bude pravděpodobně skupinové plánování nejčastěji používáno.
Jde o plánování pro jednotlivé uživatele: vytvoří se samostatná skupina pro každého uživatele na systému a s pomocí těchto skupin je každému uživateli přidělen férový podíl procesoru. Protože jsou skupiny automaticky vytvářeny plánovačem, není nutné mít pro ovládání skupin samostatné rozhraní. Místo toho se zvolí konfigurační volba "férové uživatelské" a skupinové plánování pro jednotlivé uživatele se zapne bez jakéhokoliv dalšího zásahu.
Je samozřejmé, že jakmile začne systém poskytovat férové plánování pro jednotlivé uživatele, administrátoři budou chtít, aby férové nebylo, a zařídí, aby někteří uživatelé dostali více procesoru než jiní. Léty prověřený způsob zvyšování priority toho nezbytně důležitého administrátorského procesu wesnoth pořád funguje, ale je to hrubé a průhledné řešení. Bylo by mnohem lepší mít možnost vyladit plánovač tak, aby jistí uživatelé dostali vyšší díl procesoru pro provozování svých zásadních her video diagnostických nástrojů.
Aby se podobného účinku dosáhlo s plánovačem v 2.6.24, bude pouze nutné jít do nového adresáře /sys/kernel/uids. Tam bude podadresář pro každé aktivní uživatelské ID na systému a každý podadresář bude obsahovat soubor nazvaný cpu_share. Výchozí celočíselná hodnota v tomto souboru bude 1024. Pro účely úprav plánování je podstatný pouze poměr hodnoty cpu_share vůči dalšímu uživateli. Je-li cpu_share jednoho uživatele nastaveno na 2048, dostane takový uživatel dvakrát více procesoru než kterýkoliv další uživatel, jehož hodnota zůstala 1024. Výsledkem je to, že úprava plánování procesoru mezi uživateli je pro administrátory velmi jednoduchá.
Do 2.6.24 bylo také začleněno docela dost dalších patchů. Většinou jde o pročišťování a menší vylepšení. Některé počty v rámci plánovače byly zjednodušeny a několika způsoby byla zlepšena férovost. Přibyla také možnost provádět správu procesorových zdrojů pro hostované virtualizované systémy běžící pod KVM. Patchů je to hodně, ale tempo změn v jádře plánovače procesoru by se mělo už zase začít zpomalovat.
Pracuje se však ještě na dalších věcech souvisejících s plánovačem. Dvě z nich řeší problém, jak rychle dostat do procesoru realtimové úlohy. Za normálních podmínek se plánovač bude docela dost snažit, aby nemusel přesouvat procesy mezi procesory, protože režie takové migrace (způsobená ztraceným obsahem keše paměti) je vysoká. Pokud však chce běžet realtimový proces, musí mu systém poskytnout procesor i za cenu snížení celkové propustnosti. Aktuální plánovač však nechá realtimový proces čekat, běží-li na stejném procesoru proces s vyšší prioritou, i když jsou v systému k dispozici jiné procesory.
Nápravou tohoto problému se zabývají dva patche. První od Stevena Rostedta řeší situaci, při které plánování jedné realtimové úlohy způsobuje vyšoupnutí úlohy s nižší prioritou (ale i tak realtimové) z procesoru. Než aby ta jedna smolařská úloha zůstávala ve frontě, prohledává Stevenův patch ostatní procesory v systému, aby našel ten, kde běží proces s nejnižší prioritou. Podaří-li se nalézt procesor s procesem s dostatečně nízkou prioritou, bude na něj přesunut vyšoupnutý realtimový proces.
Gregory Haskins poslal podobný patch, který řeší mírně odlišnou situaci: právě byla probuzena realtimová úloha, ale procesor, na kterém je, už provádí proces s vyšší prioritou. Opět následuje hledání procesoru s procesem s nízkou prioritou, přičemž realtimový proces je přesunut, pokud se podaří vhodnější procesor najít. V obou případech přesouvaný proces výkonnostně trochu utrpí, protože na něj čeká úplně čistá keš. Ale i tak bude schopen reagovat mnohem rychleji, než kdyby někde seděl ve frontě; a o to především u realtimového plánování jde.
Další potíž, která se v některých situacích projevuje, je to, že je přesnost plánování omezena tikovou frekvencí plánovače. V případě absence externích událostí (třeba dokončení I/O operací) může jeden proces předejít jiný jen při dalším periodickém tiku. V důsledku toho mohou procesy běžet déle, než by jim jejich přidělený časový úsek jinak dovolil. Plánovač to kompenzuje tak, že nechá daný proces déle čekat na svůj další příděl. Plánování je tedy férové, ale s vyššími latencemi.
Peter Zijlstra poslal řešení tohoto problému: patch, který používá mechanismus časovačů s vysokým rozlišením, aby dosáhl preempce procesů přesně s vypršením jejich časových přídělů. Když si plánovač všimne, že časový úsek vyprší v době mezi tiky časovače, zařídí speciální jednorázové časovačové přerušení pro okamžik vypršení časového přídělu. Když pak přijde přerušení, může být běžící proces vykopnut přesně na čas. Díky tomu nepřetáhne proces svůj příděl a nebude muset před dalším přídělem čekat déle než obvykle.
Mike Galbraith hlásil, že tento patch má na jeho systému za následek méně přepínání kontextů a také vyšší propustnost. Vypadá to tedy jako správné řešení problému - když není k dispozici mechanismus pro opravdu dynamický tik. Stávající kód implementující dynamický tik vypíná při nečinnosti procesoru periodické časové přerušení, ale při zaměstnaném procesoru přerušení dále běží. V plně dynamickém prostředí by periodické tiky vůbec nebyly používány a speciální přerušení na konci časových přídělů by byly běžný způsob práce. Implementace plně dynamického tiku je však velký úkol; mezitím může plánovači s přesností pomoci občasný extra tik.
Hluboko utopena v závalu patchů pro 2.6.24 je sada významných změn v interním API VFS vrstvy. Hlavní motivací této práce je snaha zabránit problému se zatuháváním, kterému se starým API nešlo předejít bez výrazného poklesu výkonnosti. Všichni, kteří spravují souborové systémy mimo hlavní jádro, by se na změny měli podívat a připravit se na opravu svého kódu.
Ve starším VFS API poskytovaly souborové systémy pro podporu zápisů do souborů dvě operace s adresními prostory:
int (*prepare_write)(struct file *file, struct page *page,
unsigned begin, unsigned end);
int (*commit_write)(struct file *file, struct page *page,
unsigned begin, unsigned end);
Volání prepare_write() uvědomí souborový systém, že se VFS chystá zapisovat bajty begin..end z file do dané page. Pak už musí souborový systém zařídit, aby zápis fungoval (včetně alokace bloků, je-li to třeba). Má-li být zapsána jen část bloku, měl by souborový systém vyplnit page se všemi daty bloku. Později volání commit_write() řekne souborovému systému, že byla data zkopírována do page, a mohou být uložena na disk.
Potíž s tímto API je v tom, že od VFS se očekává předání zamčené stránky do prepare_write(). Existuje několik postupů, které mohou vést ke snaze uzamknout tu stránku dvakrát, což by systém zastavilo. Aby se problému předešlo, vytvořil Nick Piggin náhrady za prepare_write() a commit_write():
int (*write_begin)(struct file *file, struct address_space *mapping,
loff_t pos, unsigned len, unsigned flags,
struct page **pagep, void **fsdata);
int (*write_end)(struct file *file, struct address_space *mapping,
loff_t pos, unsigned len, unsigned copied,
struct page *page, void *fsdata);
Je tam dost změn, ale klíčová je skutečnost, že stránka už není předávána do write_begin(). Místo toho by měla funkce alokovat stránku sama a vrátit ji (zamknutou) VFS. Volání write_end() značí, že je zápis kompletní; mělo by stránku odemknout a aktualizovat pole i_size inody.
Důležitý je také nový parametr copied: je to počet bajtů, které byly na stránku opravdu nakopírovány - může být menší než předpokládaná len. Některé z možných případů zamrznutí se vyskytly při zpracovávání výpadků stránek, zatímco byla cílová stránka uzamčena; triviálním příkladem je zápis dat na stránku, zatímco jsou stejná data zároveň z dané stránky čtena. S novým API se výpadek stránky při kopírování dat přeruší, což umožní odemknutí stránky. Výpadek může být zpracován, když je stránka odemknuta, a tím se zabrání zatuhnutí.
Možnost krátkých zápisů klade na souborové systémy extra nároky: data, která je možné přepsat, musí být stejně načtena - pro případ, že by operace zápisu skončila předčasně. Existují však situace, kdy VFS ví, že zápis doběhne až do konce; především zápisy z bufferů v jaderném prostoru musejí uspět. Když je takový zápis spuštěn, VFS předá příznak AOP_FLAG_UNINTERRUPTIBLE do write_begin(), aby dal souborovému systému vědět, že krátké zápisy nejsou možné.
Prozatím jsou VFS metody prepare_write() a commit_write() v jádře stále podporovány. Pokud souborový systém neposkytuje nové funkce, použijí se staré. Do budoucna je však určitě v plánu tyto metody odstranit; nelze je podporovat tak, aby byly zároveň bezpečné a rychlé.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Skupinové plánování však nečeká; do 2.6.224...
Alokace čísel UDP portů je teď náhodná.
6.11.2007 03:54
Prcek | skóre: 43
| Jindřichův Hradec / Brno
6.11.2007 06:46
Pavel Vymetálek | skóre: 15
| Náchod
6.11.2007 09:21
Petr Tomášek | skóre: 39
| blog: Vejšplechty
doer - muž činu doer - dříč doer - člověk, který jednápredtim jsem varil z vody, ani jsem se nekoukl do puvodniho zneni, ale daleko od pravdy jsem nebyl...
Verim ze s 2.6.24 prijde enormni pocet bugu, proto jsem neupdatoval ani na 2.6.23
To se bojíte, že by část toho hmyzu mohla přelézt na sousední verzi? :-)
6.11.2007 20:24
freshmouse | skóre: 42
| blog: Bruno Banány
