Byla vydána verze 0.2.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Společnost Cloudflare jej letos v únoru uvolnila pod licencí Apache 2.0.
Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Současné vývojové jádro je stále 2.6.32-rc7 vydané 12. listopadu. Většina commitů je toho druhu, který mám v této fázi rád: Jednořádky a párřádky, ale musím přiznat, že je tam několik patchů KMS ovladače Radeon větších, než bych chtěl. Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.
Seznam regresí 2.6.32-rc7 ukazuje celkem 41 nevyřešených bodů – pro tuto fázi vývojového cyklu vysoké číslo. Do konečného vydání 2.6.32 tedy možná zbývá pár týdnů.
-- Alan Cox
-- Mel Gorman
-- Pekka Enberg
Co dělat, když máte skupinu procesů, ale chcete, aby v daný čas běžel jenom jeden z nich? Takový druh zátěže není výjimečný; objevuje se u aplikací běžících ve vláknech v uživatelském prostoru, aplikací s asynchronním I/O a u aplikací, které některé úlohy spouštějí na pozadí. Stijn Devriendt na takový problém narazil; nedávno navrhl řešení v podobě nového systémového volání:
int sched_wait_block(pid_t pid, struct timespec *uts);
Toto volání proces uspí, dokud proces označený pid není zablokován, v takovém případě se volající proces vrátí do fronty běžících. V podstatě přidává sémantiku „spusť mě jenom v případě, že proces pid spí“.
Ingo Molnár v odpovědi navrhl naprosto jiný přístup; podle něj je tento problém dalším hřebíčkem pro kladivo „událostí výkonnosti“. Proces, který má zájem, by mohl přijímat události „paralelismu“ a následně přijímat upozornění na to, že se určitý proces uspal nebo že nyní může běžet. Podle něj by tato schopnost měla skutečné výhody:
Linus nicméně navrhl něco úplně odlišného: Než vytvářet celý tento framework, stačilo by přidat do plánovače poměrně hloupý režim „z této skupiny procesů spusť naráz jenom jeden“. Tento režim, který by bylo možné specifikovat novým příznakem pro clone(), by mohl vyřešit většinu problémů v této oblasti bez přidávání sady nových komplikovaných rozhraní.
V době psaní tohoto článku je patch připojen jenom k navrženému sched_wait_block() a nikdo jiný neslíbil, že by napsal nějaký jiný. Výsledek této konverzace – pokud nějaký bude – je přinejmenším nejistý, ale v každém případě je to zajímavé prozkoumání možných přístupů.
Vývojáři pracující na implementaci kontrolních bodů/restartu v Linuxu chtějí mít možnost vytvořit nový proces se specifickým ID. Pokud tato vlastnost nebude k dispozici, restartované procesy budou najednou mít jiné PID, což může vést pouze ke zmatkům. Implementace explicitního výběru PID byla navržena v podobě různých rozšíření systémových volání clone() se jmény jako clone_with_pids() a clone_extended(). Žádná verze ještě nebyla začleněna a navrhované API se dále vyvíjí.
Nejnovější návrh se jmenuje eclone(); vypadá nějak takto:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int eclone(u32 flags_low, struct clone_args *args, int args_size,
pid_t *pids);
Parametr flags_low odpovídá parametru flags existujícího volání clone(), kterému dochází volný prostor na nové příznaky. Parametr pids je volitelný seznam PID, která se mají aplikovat na proces potomka, pro každý jmenný prostor, ve kterém se proces objevuje, jeden. Všechno ostatní patří do args:
struct clone_args {
u64 clone_flags_high;
u64 child_stack_base;
u64 child_stack_size;
u64 parent_tid_ptr;
u64 child_tid_ptr;
u32 nr_pids;
u32 reserved0;
u64 reserved1;
};
Několik z těchto polí (child_stack_base, child_stack_size, parent_tid_ptr, child_tid_ptr) odpovídá argumentům existujícího clone(). clone_flags_high umožňuje přidání dalších příznaků; v návrhu eclone() nicméně žádné nové příznaky definovány nejsou. Délka pole pids je dána nr_pids a pole reserved jsou pro další rozšiřování v budoucnosti.
Komentářů se k tomuto novému návrhu objevilo jenom pár; to může být tím, že komunita vývojářů je již unavena, protože tyto patche vidí znovu a znovu. Ticho také může znamenat, že k tomuto návrhu nejsou žádné námitky. Jedna velká překážka tomuto systémovému volání nicméně zbývá: Má sloužit k podpoře kontrolních bodů/restartu, které rozhodně k začlenění do hlavní řady připraveny nejsou. Dostat tuto funkci do stavu „dokončeno a udržovatelné“ pravděpodobně nějaký čas zabere; do té doby může být odpor k tomu přidat nové systémové volání, které ještě nemá žádné uživatele v reálném světě.
Na první pohled je správa paměti jednoduchý úkol. Když dochází paměť, kód VM jednoduše potřebuje odklidit stránky, které se nejdéle nepoužívaly, a zpřístupnit tak jejich paměť. Ta těžká část je samozřejmě identifikace takových stránek; vzhledem k tomu, že nejsou k dispozici perfektní předpovědi budoucího využívání paměti, musí subsystém VM spoléhat na sadu heuristik, ze kterých usuzuje na (snad) nejrozumnější možnosti. Návrh heuristik, které dokáží zvládnout většinu pracovních zátěží, je ale záludný a i malé změny v kódu mohou vést k velkým změnám v chování systému.
Od počátku vývojového cyklu 2.6.31 si někteří uživatelé stěžují na nárůst počtu selhání alokací paměti jádrem, což vede ke zprávám v logu, pádům aplikací a občasné nevítané návštěvě OOM zabijáka. Bylo nahlášeno několik chyb (vizte například #14141 a 14265) a hodně lidí se škrábalo na hlavě. Jenom pár vývojářů ale ví, kde hledat příčiny tohoto druhu problémů, a někteří z toho mála se navíc spokojili s prohlášením, že problém je způsoben alokacemi vyšších řádů. Opravování tedy bylo pomalé.
Alokace vyšších řádů (vícestránkové) jsou u linuxových systémů přetrvávajícím problémem; jak se paměť fragmentuje, je čím dál tím těžší najít fyzicky spojité stránky, kterými by bylo možné uspokojit požadavky na takové alokace. Kdekoliv je to možné, je jaderný kód psán tak, aby se alokacím vyšších řádů vyhýbal, ale to je občas obtížné. Mnoho z nedávno hlášených problémů, zdá se, souvisí s určitými ne zcela špičkovými bezdrátovými síťovými adaptéry, které ke své práci potřebují spojité kousky paměti. Oprava problému je důležitá – i uživatelé s levnými síťovými kartami chtějí používat Linux – ale objevují se i hlášení o selhání alokací samostatných stránek.
Mel Gorman se naštěstí nebojí do této části jádra vkročit; věnoval čas snaze problém reprodukovat a pochopit, co se od 2.6.30 pokazilo. Zaslal sérii pěti patchů, která se snaží pravděpodobnost selhání alokace zase snížit. Pohled na to, co Mel udělal, poskytuje dobrou lekci toho, jak křehký může tento druh programování být.
Když se na tento kód díváme, je dobré mít na mysli to, že jádro má k dispozici dva fundamentální mechanismy pro uvolňování paměti, když ji potřebuje pro nové alokace. Přímé znovuzískávání [direct reclaim] je aktivní čistění paměti během alokace; když se alokace nezdaří, proces, který se o ni pokoušel, zkusí uvolnit paměť někde jinde v systému. Přímé znovuzískávání má výhodu v tom, že je okamžité – pracovat se na něm začne okamžitě, když nedostatek paměti udeří – a že práci přehazuje na procesy, které paměť alokují; na druhou stranu je omezené, jak dlouho může jeden proces znovuzískávat paměť, aniž by se do něj zavedly neakceptovatelné latence. Rozsáhlejší pročišťování je tedy vytlačeno do jaderného vlákna kswapd, které je k tomu určeno.
Současná jádra hlavní řady neprobouzí kswapd z kódu přímého znovuzískávání v případě, že tato operace neuspěje. Pokud je ale paměti tak málo, kswapd by měl běžet, obzvláště když jsou zapotřebí alokace vyšších řádů. První patch Melovy série je tedy jednoduchý jednořádek, který způsobí, že se kswapd probudí při selhání přímé alokace a možná že bude také intenzivněji pracovat na uvolnění kousků vyššího řádu. Tato změna chování vrací někam blíže k tomu, co dělala starší jádra.
Patch #2 je jednoduché ladění, které brání obsluhám přerušení běžícím v reálném čase příliš vytěžovat kód alokace paměti. To je opět návrat k chování, které bylo k vidění ve dnech 2.6.30.
Třetí patch je o trochu jemnější. Přímé znovuzískávání, když je úspěšné, vede k vytvoření I/O operací, které zapisují špinavé stránky na jejich úložiště. Počet blokových I/O operací, které čekají na vyřízení, je nicméně omezený; jakmile se dosáhne limitu, zařízení je označeno za „přetížené“ a úloha provádějící znovuzískávání je nucena čekat, dokud se věci trochu nepročistí. Toto „čekání kvůli přetížení“ brání v tom, aby se systém přeplnil čekajícími I/O operacemi, a slouží jako omezovač procesů, které alokují paměť.
Ve skutečnosti jsou dvě fronty pro „čekání v zácpě“ – jedna pro synchronní a jedna pro asynchronní požadavky. „Synchronní“ požadavky jsou ty, na které aktivně čeká nějaký proces – obvykle požadavky na čtení – zatímco asynchronní jsou ty, na které nikdo nečeká. V současných jádrech přímé znovuzískávání čeká na asynchronní frontu, zatímco starší jádra místo toho používala frontu synchronní. Přechod zpět na synchronní frontu mnoho problémů řeší, ale to Mel považuje za opravu specifickou pro určitý typ zátěže. Místo toho změnil kód pro přímé znovuzískávání tak, aby čekal, než se „přetížení“ vyčistí v obou frontách.
Proč to pomůže? Zdá se, že jde o to, aby se kswapd umožnilo pracovat. Kswapd také musí čekat, když se fronty požadavků zaplní; pokud přímé znovuzískávání často zaplňuje I/O fronty, kswapd musí čekat častěji. Ukazuje se přitom, že lepších výsledků je dosaženo, když kswapd může běžet déle. Když je přímé znovuzískávání přinuceno čekat, než se vyčistí obě fronty, umožňuje to kswapd – když už se rozeběhlo – udělat nějakou práci. To je dobré pro vytváření oblastí paměti vyšších řádů a pro výkonnost systému celkově.
Patch #4 se také vztahuje k práci kswapd. Jakmile kswapd usoudí, že toho udělal dost, přestane pracovat a uspí se; jednou z definicí „dost“ je, když množství volné paměti dosáhne hodnoty horního vodoznaku [watermark]. Jestliže ale kswapd běží, je velká šance, že v systému jsou nesplněné požadavky na paměť; v takové situaci množství volné paměti nezůstane nad horním vodoznakem dlouho. Melův patch zajišťuje, že si kswapd nejprve malinko zdřímne, místo toho aby se hned uspal; po 0,1 sekundy se znovu probudí a zhodnotí situaci. Pokud množství volné paměti klesne pod vodoznak, začne kswapd zase pracovat; jinak se definitivně uspí. Tímto způsobem je zajištěno, že je paměť uvolňována v případě, že ji systém rychle spotřebovává.
Poslední patch se dotýká dalšího aspektu čekání při přetížení. Když je blokové zařízení přetíženo, kswapd čeká, až se věci pročistí. Jak ale Mel podotýká, to nemusí být ve všech situacích nejlepší:
V původní verzi patche byl kswapd čím dál tím odolnější vůči čekání při přetížení, když se situace zhoršovala. Motohiro Kosaki ale navrhl alternativní přístup, kde kswapd prostě odmítne čekat, dokud není dosaženo horního vodoznaku, a Mel ho přijal.
Melův patch obsahuje slušné množství informací o tom, jak ho testoval a jaké byly výsledky. Po aplikování této sady patchů je méně selhání alokací a propustnost systému se také zvyšuje. Smutná pravda o patchích správy paměti je nicméně ta, že změna, která prospěje jednomu typu zátěže, může poškodit jiný. Tyto změny tedy skutečně potřebují široké testování, obzvláště vzhledem k tomu, že je zájem dostat je do 2.6.32.
Současný síťový hardware může přenášet spousty paketů až do té míry, že hostitelský počítač může mít problém to stíhat. V nedávné době se rychlosti CPU přestaly zvyšovat, ale počet jader dále roste. Co z toho plyne, je jasné: Pokud má síťový stack držet tempo s hardwarem, chytřejší zpracování (jako obecné odlehčování při příjmu) nebude stačit; systém také bude muset být schopen dělit práci mezi několik procesorů. Patch Toma Herberta pro směrování příchozích paketů [receive packet steering, RPS] v tom má pomoci.
Z pohledu operačního systému je distribuce práce s odchozími daty mezi několik CPU relativně přímočará. Procesy generující data se v systému přirozeně rozloží, takže se síťový stack nemusí o moc starat, obzvláště když jsou nyní podporovány vícenásobné odesílací fronty. Rozložit příchozí data je však složitější, protože pochází z jednoho zdroje. Některá síťová rozhraní mohou při dělení práce s příchozími pakety pomoci; mají několik přijímacích front a několik přerušovacích linek. Jiná jsou ale vybavena jedinou linkou, což znamená, že ovladač takového hardwaru se musí se všemi pakety vyrovnat v jediném serializovaném proudu. Paralelizace takového proudu vyžaduje nějaké schopnosti na straně operačního systému.
Tomův patch poskytuje tyto schopnosti zaháčkováním se na přijímací cestě – v netif_rx() a netif_receive_skb() – přímo tam, kam ovladač předává paket do sítového subsystému. V tomto místě vytváří hash relevantních dat protokolu (konkrétně IP adres a čísel portů) a ten používá k výběru CPU; paket je následně naplánován pro obsluhu cílovým CPU. Ve výchozím stavu je práce mířena na všechna CPU v systému, ale seznam CPU, které má konkrétní rozhraní využívat, může správce systému nastavit, pokud potřebuje.
Kód je relativně jednoduchý, ale úspěšně rozprostírá zátěž vznikající přijímáním dat na celý systém. Používání hashe je důležité: Zajišťuje, že pakety ze stejného proudu dat skončí na stejném procesoru, což zvyšuje lokalitu cache (a tím výkonnost). Toto schéma je také hezké v tom, že nevyžaduje žádné změny ovladačů, takže ho lze nasadit rychle a s minimálním rušením jinde.
Jedno místo, kde mohou ovladače pomoci, však je. Výpočet hashe vyžaduje přístup k datům z hlavičky paketu. Tento přístup nutně znamená jeden i více pokusů o čtení dat, která nejsou v cache CPU, na kterém běží směrovací kód – data do paměti právě vložilo síťové rozhraní, takže v cache CPU být nemohou. A jakmile je paket předán CPU, které bude odvádět práci, pravděpodobně dojde k témuž. Zpoždění vznikající nutností čekat na data z paměti jsou pro rychlou práci se sítí zhoubná; jejich odstraňování bylo věnováno hodně práce všude, kde to bylo možné. Přidat takové zpoždění pro každý paket v kódu směrování by bylo kontraproduktivní.
Ukazuje se, že mnoho síťových rozhraní je schopno samo o sobě hodnotu hashe příchozích paketů vypočítat. Toto zpracování je zdarma a mohlo by eliminovat potřebu hash počítat na procesoru, který práci rozděluje (a tím odbourat zpoždění při přístupu k datům). Patch RPS toho využívá a přidává do struktury sk_buff (SKB) pole rxhash. Ovladače, které jsou schopny získávat hodnoty hashe přímo z hardwaru, je mohou do SKB vložit; síťový stack poté přeskočí výpočet vlastní hodnoty. To by mělo udržet data paketu mimo cache CPU dělícího práci úplně, čímž se zpracování zrychlí.
Jak dobře to funguje? Patch zahrnuje výsledky nějakých benchmarků z nástroje netperf. Osmijádrový server se síťovými rozhraními založenými na tg3 zrychlil z 90 000 transakcí za sekundu na 285 000; adaptér založený na e1000 na stejném systému měl nárůst z 90 000 na 292 000. Podobné výsledky se objevily i na čipových sadách nForce a bnx2x na šestnáctijádrových serverech. Zdá se, že patch dokázal zrychlit síťové zpracování na vícejádrových systémech.
Patch shodou okolností pochází od Googlu, který nějaké zkušenosti s prací v síti má. Na produkčních serverech Googlu evidentně nějakou dobu běžel; patch RPS je tedy snad první kapkou v širokém proudu příspěvků Googlu, jak se tato firma snaží těsněji pracovat s hlavní řadou jádra. Zdá se to být dobrý start.
I když je dnes vcelku běžné, že domácí elektronika – televize, DVD recordery a podobné – běží na Linuxu, najít projekt, jehož cílem je nahrazovat a aktualizovat linuxový firmware v těchto zařízeních, tak běžné není. Přesně o to se ale snaží projekt SamyGO u televizí Samsung. S použitím zdrojových kódů, které Samsung poskytl, a s trochou vynalézavosti SamyGO umožňuje uživatelům připojit se ke své televizi – poměrně zábavný koncept – a také umožnit funkcionalitu, která sahá za to, co se se zařízením dodává.
Wiki SamyGO obsahuje seznam několika modifikací firmwaru televize. Jednou z hlavních modifikací je povolení podpory NFS nebo SMB/CIFS, což umožňuje přehrávat média ze serverů v síti. TV již má podporu pro získávání médií z lokální sítě použitím protokolů Digital Living Network Alliance (DLNA), ale to má v závislosti na použitém DLNA serveru omezení audio a video formátů a také funkcí při přehrávání (pauza, posouvání vpřed a vzad.) S použitím NFS nebo CIFS jsou přes síť k dispozici všechny formáty a vlastnosti dostupné pro přehrávání založené na USB.
Zde se zjevně jedná o high-endové televize, které mají jak možnost připojení k ethernetové síti, tak USB porty. Zařízení „podporovaná“ SamyGO jsou LCD modely sérií LE-32-55Bxxx a LED televize od série UE-xx-B70xx. USB porty jsou k dispozici pro přehrávání/prohlížení připojitelných médií nebo pro hry. Použití menu „Games“ s programy uloženými na USB disku je jedním ze způsobů, jakým na televizi spustit programy.
USB porty se také používají k připojování WiFi adaptérů Samsung, které si vlastník televize může koupit, aby se vyhnul nutnosti tahat dráty. Linux ale podporuje mnohem více bezdrátových zařízení, takže vývojáři SamyGO pracují na tom, aby umožnili použít i jiná. Ovladače Ralink rt73 a rt2870 byly v jádře od Samsungu modifikovány tak, že byla odstraněna některá ID zařízení, aby s danými ovladači fungovala jenom zařízení od Samsungu. Nyní jsou k dispozici ovladače bez tohoto omezení.
První pokusy byly věnovány zprovoznění telnetu, aby bylo možné prozkoumat souborový systém v televizi. To je možné patchováním binárky firmwaru poskytovaného Samsungem a následně jeho instalací použitím mechanismu pro upgrade firmwaru v televizi. Příhodně pojmenovaná zpráva Varování: tohle čtěte nebo ze své televize uděláte velkou cihlu! na fóru SamyGO popisuje nebezpečí aktualizací firmwaru. Ti, kdo tohle všechno chtějí jenom vyzkoušet bez změn firmwaru, mohou použít bezpečnější metodu, která se maskuje jako hra na USB disku a která povoluje telnet.
Jádro je založené na 2.6.18 s přídavkem Robustního souborového systému FAT [Robust FAT file system, RFS], což je souborový systém pro flash zařízení založená na technologii NAND. Jak naznačuje jméno, je kompatibilní s FAT, ale v hlavní řadě není a vývojáři SamyGO ho ani nerozběhali pro desktopové distribuce. Z tohoto důvodu se uchýlili k binárnímu patchování firmwaru.
Samsung vydal i zdrojové kódy RFS společně s příručkou pro portování na Linux. Jakmile bude možné RFS přeložit pro současná jádra nebo pokud vznikne nástroj pro vytváření obrazů RFS, budou vývojáři schopni pro tyto televize vytvářet své vlastní obrazy firmwaru. [Aktualizace: vizte komentáře pod originálem článku, žádné zdrojové kódy RFS vydány nebyly.]
Zdrojové kódy jádra jsou k dispozici, ale projekt ještě nevydal žádné jádro z nich přeložené. Byly nicméně přeloženy ovladače Ralink po modifikaci ID zařízení, takže je možné je do systému vložit. Jádro samo o sobě bylo modifikováno, mezi jinými věcmi do něj byla přidána podpora pro architekturu OMAP a zvuk, ale ve fóru není žádná zmínka o binárních ovladačích, takže by vydané jádro – nebo něco aktuálnějšího – mělo být možné přeložit.
Samsung zatím na projekt podle všeho nijak nereagoval, ani pozitivně, ani negativně. Na fóru se objevily obavy, že obejití omezení WiFi by mohlo firmu rozhněvat – na druhou stranu lze hádat, že jenom málokdo bude ochoten riskovat rozbití drahé televize kvůli tomu, aby mohl použít levnější WiFi adaptér – takže si toho Samsung pravděpodobně nebude všímat.
Pokud ale vývojáři SamyGO přidají další funkce, které by mohly být zajímavé pro zákazníky – mluvilo se například o webovém prohlížeči – mohl by Samsung projekt adoptovat. Tak nebo tak, kód je venku pro ty, kteří ho chtějí vyzkoušet.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
17.12.2009 07:20
Jan Drábek | skóre: 41
| blog: Tartar
| Brno
Ukazuje se, že mnoho síťových rozhraní je schopno samo o sobě hodnotu hashe příchozích paketů vypočítat.mi tak trochu vyrazilo dech.
17.12.2009 11:27
20.12.2009 15:30