Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Aktuální předverze řady 2.6 je (k 18. 4. 2007) 2.6.21-rc7, vydaná 15. dubna. Seznam oprav je relativně krátký; další verze, která už by měla přijít každou chvíli, bude 2.6.21.
Od vydání -rc7 bylo do hlavního git repozitáře začleněno přibližně 30 oprav. Mimo jiné i odstranění nepoužívané funkce alloc_skb_from_cache().
Aktuální stabilní jádro je 2.6.20.7, vydané 13. dubna. Obsahuje opravy asi desítky vážných problémů.
Starší jádra: 2.6.16.47 bylo vydáno 14. dubna a 2.6.16.48 16. dubna. Obě obsahují kolem deseti oprav, z nichž některé se týkají bezpečnosti.
Takže tvrdím, že pokud to neumí být fér podle uživatelských ID, tak to ve skutečnosti VŮBEC spravedlivé není. Myslím, že je naprosto STUPIDNÍ nazývat něco "Úplně spravedlivý plánovač", když je to fér jen na úrovni vláken. To není spravedlivé ANI TROCHU! To je opak spravedlivosti!
Prostě mi to připomíná, že koncept "vydávat brzy, vydávat často" u jádra nefunguje. Daleko více je to "kód vydávej, jen když má tak blízko k dokonalosti, že si na něj nikdo nemůže stěžovat", protože většinu práce dělá jeden člověk - jinak se objeví někdo s protipatchem, který je _kompletní_ dříve, ale s největší pravděpodobností ne tak dobrý, jen dříve hotový.
-- Con Kolivas
RSDL scheduler (mezitím přejmenovaný na "staircase deadline scheduler") od Cona Kolivase byl určitou dobu považován za kandidáta k zařazení do jádra, možná už do 2.6.22. Potíže s některými druhy zátěží způsobily, že budoucnost tohoto plánovače už tak jistá není. Teď to vypadá, že si Con vzpomněl na jeden z nejspolehlivějších způsobů, jak dostat do jádra nový nápad: představit kód a pak si počkat, až ho Ingo Molnar během dvoudenního kódovacího maratonu celý přepracuje. Takže ačkoliv Con nedávno vydal aktualizovaný patch s SD plánovačem, zdá se, že by jeho práce mohla být nahrazena novým kódem od Inga: completely fair scheduler (CFS, úplně spravedlivý plánovač). V tuto chvíli už ve druhé verzi.
CFS má několik zajímavých aspektů. Především zcela odstraňuje pole front. Místo toho CFS pracuje s jediným red-black stromem, pomocí kterého sleduje všechny procesy ve spustitelném stavu. Proces, který se objeví na uzlu stromu nejvíce vlevo, je ten, který má největší šanci běžet v kteroukoliv dobu. Takže základem k porozumění tomuto plánovači je získat představu o tom, jak vypočítává klíčovou hodnotu používanou pro vložení procesu do stromu.
Je to docela jednoduchý výpočet. Když se úloha ocitne ve frontě ke spuštění, zaznamená se aktuální čas. Zatímco proces čeká na procesor, plánovač sleduje množství procesorového času, na který by proces měl mít nárok; tento nárok je prostě doba čekání vydělená počtem běžících procesů (opraveno s ohledem na různé hodnoty priorit). Lze tedy říci, že klíčem je množství procesorového času, který by měl proces dostat, přičemž procesy s vyšší prioritou dostanou trochu přilepšeno. Krátkodobá priorita procesu se proto bude lišit podle toho, jestli svůj rovný díl procesoru dostává nebo ne.
Kdybychom řekli, že výše uvedený popis vysvětluje celý CFS plánovač, bylo by to odpustitelné zjednodušení. Žádné sledování doby spánku, žádné pokusy o zjištění interaktivních procesů atd. CFS plánovač v podstatě ruší i koncept časových úseků [time slices]; všechno je otázka toho, jestli daný proces dostává takový podíl procesoru, na jaký má nárok - vzhledem počtu procesů, které se snaží běžet. CFS nabízí jedinou nastavitelnou hodnotu: "granularitu", která popisuje, jak rychle bude plánovač přepínat procesy, aby udržel spravedlivý chod. Nízká granularita určuje častější přepínání; to se projeví nižší latencí interaktivních reakcí, ale může také lehce snížit propustnost. Serverové systémy pravděpodobně poběží lépe s vyšší hodnotou granularity.
Ingo tvrdí, že CFS plánovač poskytuje solidní a férové interaktivní reakce v téměř všech situacích. Existuje spousta nehezkých programů, které se současným plánovačem interaktivitu zlikvidují; Ingo říká, že žádný z nich nemá vliv na interaktivitu při použití CFS.
CFS byl představen ještě s jednou funkcí, která překvapila skoro všechny, kdo tuto oblast vývoje jádra sledují: systémem modulárních plánovačů. Ingo to popisuje jako "rozšiřitelnou hierarchii plánovacích modulů", ale v tom případě je to hierarchie bez větví. Jde o jednoduchý spojový seznam modulů seřazených podle priority; první plánovací modul, který dokáže najít spustitelný proces, se může rozhodnout, kdo přijde na řadu jako další. V současné době jsou k dispozici dva moduly: CFS plánovač a zjednodušená verze real-time plánovače. Real-time plánovač je v seznamu na prvním místě, takže všechny real-time úlohy poběží před ostatními procesy.
Oba plánovací moduly implementují relativně malou sadu metod. Funkce pro zařazení do fronty:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
void (*enqueue_task) (struct rq *rq, struct task_struct *p);
void (*dequeue_task) (struct rq *rq, struct task_struct *p);
void (*requeue_task) (struct rq *rq, struct task_struct *p);
Když se úloha dostane do spustitelného stavu, předá ji hlavní plánovač prostřednictvím enqueue_task() příslušnému plánovacímu modulu; úloha, která již není spustitelná, je odebrána pomocí dequeue_task(). Funkce requeue_task() dává proces za všechny ostatní procesy se stejnou prioritou; používá se pro implementaci sched_yield().
Několik funkcí, které plánovači pomáhají sledovat procesy:
void (*task_new) (struct rq *rq, struct task_struct *p);
void (*task_init) (struct rq *rq, struct task_struct *p);
void (*task_tick) (struct rq *rq, struct task_struct *p);
Při vytvoření nové úlohy zavolá hlavní plánovač task_new(). task_init() inicializuje všechny potřebné výpočty a další věci; může být například zavolána při změně hodnoty nice. Funkce task_tick() je volána tikem časovače kvůli aktualizaci počtů a případně přepnutí na jiný proces.
Hlavní plánovač se může plánovacího modulu zeptat, jestli by měla být u právě vykonávaného procesu zapnuta preempce:
void (*check_preempt_curr) (struct rq *rq, struct task_struct *p);
V CFS plánovači tato kontrola testuje prioritu daného procesu vůči prioritě aktuálně běžícího procesu, což je ještě následováno testem férovosti. Když je test férovosti proveden, vezme se v potaz granularita plánování a procesu tak může být dovoleno běžet ještě o něco déle, než by umožňovala striktní férovost.
Když je na čase, aby si hlavní plánovač vybral proces, který má běžet, použije tyto metody:
struct task_struct * (*pick_next_task) (struct rq *rq);
void (*put_prev_task) (struct rq *rq, struct task_struct *p);
Volání pick_next_task() plánovací modul požádá, aby se rozhodl, který proces (z těch, které jsou ve třídě spravované daným modulem) by měl právě běžet. Jakmile je úloha z procesoru vyhozena, modul o tom bude informován voláním put_prev_task().
A nakonec dvě metody určené k udržování rovnoměrného zatížení procesorů:
struct task_struct * (*load_balance_start) (struct rq *rq);
struct task_struct * (*load_balance_next) (struct rq *rq);
Tyto funkce implementují jednoduchý iterátor, který může plánovač použít k procházení všech procesů, o něž se právě plánovací modul stará.
Dá se předpokládat, že takový systém by mohl být v budoucnu využit k implementaci jiných plánovacích režimů. Možná bude potřeba některé věci doplnit; například není možné plánovací moduly upřednostňovat (nebo vybrat výchozí modul) jinak než změnou zdrojového kódu. Kromě toho, pokud by někdo chtěl implementovat moduly, které by úlohy plánovaly na stejné, obecné úrovni priority, muselo by se změnit striktně prioritní řazení stávajícího systému - a to by byla zajímavá práce. Ale je to začátek.
Důvod, proč je tento vývoj tak překvapivý, spočívá v tom, že o modulárních plánovačích nikdo nikdy pořádně nemluvil. A důvodem toho mlčení je fakt, že zasouvatelné plánovací systémy lidé v minulosti jasně odmítli - Ingo Molnar také:
Takže plánovací pluginy považuji za ekvivalent STREAMS u plánovačů a nadšený z nich nejsem. Stejně jako STREAMS, i 'pluginy plánovačů' jsou podle mě snadný ale zrádný způsob řešení současných problémů, který vytvoří mnohem větší problémy než ty, které se snaží řešit.
Otázka tedy zní: co se změnilo? Ingo poslal vysvětlení, které je dost dlouhé, ale v podstatě říká, že dřívější patche se zasouvatelnými plánovači byly zaměřeny na nahrazení celého plánovače místo menších částí; nesnažily se plánovač zjednodušit.
Takže teď jsou na stole tři návrhy pro nahrazení plánovače - SD: Con Kolivas, CFS: Ingo Molnar a "nicksched": Nick Piggin (již dlouho existující projekt, který si tu také zjevně zaslouží zmínku). Prozatím to vypadá, že se Con rozhodl sebrat svoje bábovičky a jít domů, což odstraňuje SD z obrazu. I tak je však několik možností a (prozatím) velká šance k nahrazení hlavního procesorového plánovače. Přestože Ingova práce byla přijata povětšinou kladně, ani on asi nedostane možnost udělat takové rozhodnutí sám; dá se očekávat pořádná diskuze, než k vlastnímu nahrazení dojde. Kromě jiného to také naznačuje, že v 2.6.22 nový plánovač asi nebude.
Kdokoliv se někdy snažil zjistit, proč linuxovému systému dochází paměť, může potvrdit, že informace o využití paměti, které dává k dispozici jádro, jsou přinejmenším těžko použitelné. Matt Mackall začal nedávno pracovat na sadě patchů, které si kladou za cíl tuto situaci zlepšit. Vzhledem k omezením embedded linuxových systémů není překvapivé, že si pro prezentaci své práce Matt vybral Embedded Linux Conference (kterou financovalo Consumer Electronics Linux Forum).
Matt poukázal na to, že informace v současné době dostupné jsou hodně matoucí. Stránková keš situaci znepřehledňuje a sdílení stránek mezi aplikacemi to komplikuje ještě více. Výsledkem je, že je těžké říci, kde je paměť používána; nedá se ani s určitostí odpovědět na otázku, jak velká je konkrétní aplikace. Na podrobnější otázky, například o tom, které části aplikace využívají nejvíce paměti, se odpovídá ještě složitěji. Snaha zjišťovat informace, které zajímají vývojáře embedded systémů - například kolik aplikací může běžet na konkrétním zařízení, aniž by začalo thrashovat [ukládat a načítat] - je bez provedení testu téměř marná.
Problém je, že čísla exportovaná současnými jádry jsou skoro zbytečná. Hlášená virtuální velikost aplikace je v podstatě irelevantní; neříká nic o tom, kolik z daného virtuálního prostoru je ve skutečnosti využito. Číslo RSS (resident set size = velikost residentní sady) je trochu lepší, ale chybí informace o sdílení stránek. Soubor /proc/pid/smaps nabízí nějaké detaily, ale info o sdílení tam také není. A případný nedostek paměti může situaci výrazně změnit.
Linuxový systém virtuální paměti je, jinými slovy, černá skříňka, která poskytuje příliš málo informací o tom, co se děje uvnitř. Mattův cíl je otevřít tu skříňku a trochu si dovnitř posvítit.
Prvním krokem je přidání souboru pagemap do /proc adresářů všech procesů. Je to binární soubor, který obsahuje číslo rámce stránky pro každou stránku v adresním prostoru procesu. Ze souboru lze vyčíst, kam byly umístěny stránky procesu, a, což je ještě zajímavější, může být porovnáván se soubory ostatních procesů, aby se zjistilo, které stránky jsou sdíleny. Matt napsal malý grafický nástroj, který ten soubor umí zobrazit a ukázat uspořádání stránek - které v paměti jsou, a které ne.
Další soubor je /proc/kpagemap, který poskytuje informace o paměťové mapě jádra. Pro každou fyzickou stránku v systému obsahuje kpagemap mapovací počet a příznaky stránky. To lze využít ke zjišťování informací o sdílení stránek a o tom, jak je která stránka používána. Tento soubor využívají další dvě grafické aplikace; jedna ukazuje, nakolik je stránka sdílená, zatímco druhá ukazuje využití každé stránky určené jejími příznaky.
S takovými informacemi je možné začít získávat užitečná čísla o využití paměti. Matt navrhuje dvě nová měření. "Velikost proporční sady" (PSS, Proportional Set Size) procesu je počet stránek, které má v paměti, přičemž každá stránka je vydělena počtem procesů, které ji sdílejí. Takže pokud má proces 1000 stránek jen pro sebe a 1000 sdílených s jedním dalším procesem, jeho PSS bude 1500. "Velikost unikátní sady" (USS, Unique Set Size) je obyčejný počet nesdílených stránek. Z praktického hlediska je to počet stránek, které budou systému vráceny, bude-li proces zabit.
Tato čísla není jednoduché vypočítat, protože je k tomu potřeba projít adresní prostor procesu. Není to tedy něco, co by bylo z jádra pravidelně exportováno. Mohou však být spočítána v uživatelském prostoru. Matt předvedl pár nástrojů, které tyto výpočty mohou provést. Pomocí memstats na procesu prohlížeče Galeon doplnil stávající údaje o virtuální velikosti (105 MB) a resident set size (41 MB) o nové dva údaje PSS (26 MB) a USS (20 MB). Nástroj memrank vypíše procesy seřazené podle PSS. S takovým programem je nalezení žroutů paměti hračka.
Matt vysvětlil, že tato čísla, ač užitečná, se budou měnit podle toho, jak moc bude systému chybět paměť. Bylo by fajn umět zjistit, kolik paměti proces doopravdy potřebuje, než začne thrashovat. Kvůli tomu vytváří Mattův patch pro každý proces nový soubor clear_refs; ten lze použít k resetu příznaku "referenced" na všech stránkách v pracovní sadě procesu. Po chvíli běhu procesu se můžeme podívat, kolika stránkám byl příznak "referenced" opět zapnut; to jsou stránky, které během té doby skutečně potřeboval k běhu.
V tuto chvíli jsou patche ve stromu -mm; je možné, že by si do jádra mohly najít cestu, až začne období pro začleňování patchů do 2.6.22. Pokud si chcete se skripty od Matta pohrát, najdete je na selenic.com/repo/pagemap; jsou tam i slajdy z přednášky. Při troše štěstí už v budoucnu nebude nutné tolik hádat, když budeme chtít porozumět využití paměti.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Jednou bych to nechal byt, ale uz jsem to videl docela dostkrat...Proč jsi to neřekl napoprvé?
Já prostě překlad "spojové seznamy" neznal, ale protože se nikdo neozval, tak jsem se držel toho svého.
10.5.2007 18:43
freshmouse | skóre: 42
| blog: Bruno Banány
10.5.2007 21:42
freshmouse | skóre: 42
| blog: Bruno Banány
14.5.2007 16:58
s/tákají/týkají
Takže ještě jednou díky za JN a nenechte si to překládání znechutit.Díky za povzbuzení. Musím však doplnit, že ačkoliv je mi občas líto všech, které nebaví řeči o češtinářských nebo překladatelských věcech, tak já ty opravy většinou vítám. Sice mě netěší, když někde napíšu blbost, ale jsem perfekcionista amatér, tak to beru sportovně. Je však pravda, že bylo vhodnější to řešit mailem.