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.
Současné vývojové jádro 2.6 je stále 2.6.29-rc3. V době psaní tohoto článku bylo od vydání 2.6.29-rc3 začleněno jenom něco přes 500 sad změn; většinou jde o opravy, ale také jsou mezi nimi nějaká vylepšení UBIFS (včetně podpory přímého I/O), ovladač pro PATA řadiče AMD CS5536 a podpora SPARC64 NMI watchdogu. Zkušenosti z minula naznačují, že vydání 2.6.29-rc4 lze očekávat několik milisekund poté, co bude publikována tato stránka.
Současné stabilní jádro 2.6 je 2.6.28.3 vydané 2. února; ve stejné době bylo vydáno 2.6.27.14. Obě aktualizace obsahují dlouhý seznam oprav vážných problémů.
V době psaní tohoto článku jsou aktualizace 2.6.28.4 a 2.6.27.15 revidovány; pravděpodobné datum vydání je 6. února.
-- Gustavo Duartes popisuje správu paměti.
![[graf výkonnosti]](http://www.ioremap.net/gallery/dbench_pohmelfs_vs_nfs_1.png)
-- Jevgenij Poljakov ukazuje menší výkonnostní rozdíl.
-- James Laska
Vytvoření obrazů initramfs pro použití jádrem v době "časného bootu", je poněkud zmatená záležitost. To je ještě umocněno tím, že každá jednotlivá distribuce má k vytvoření obrazu své vlastní nástroje stejně jako svou vlastní sadu nástrojů uvnitř obrazu. Na Jaderném summitu 2008 Dave Jones strávil nějaký čas diskutováním problému a návrhem začít opětovným vytvořením mezidistribučního initramfs. To vedlo k vzniku projektu Dracut, který v prosinci oznámil Jeremy Katz, a nové mailové konference, vhodně pojmenované "initramfs", ve které o něm lze diskutovat.
Initramfs je cpio archiv počátečního souborového systému, který je nahrán do paměti, když je zavedeno jádro. Tento souborový systém musí obsahovat všechny ovladače a nástroje potřebné k připojení skutečného kořenového souborového adresáře. Mít initramfs není striktně nutné, minimální /dev společně se všemi potřebnými ovladači zabudovanými do jádra je další alternativa. Všechny distribuce nicméně používají initramfs a postupem času každá přišla se svým způsobem, jak tento proces zvládnout. Davy, Jeremy a další by raději viděli něco standardizovanějšího, co by bylo protlačeno do upstreamu a distribuce by mohly přestat poskakovat okolo tohoto problému.
Tento přístup má několik výhod. Vytvoření initramfs ze zdrojových kódů jádra by odstranilo problémy, na které občas naráží uživatelé, kteří si překládají vlastní jádro. Jestliže se schéma initramfs v distribuci nějakým způsobem opozdí za tempem vývoje jádra, uživatelé mohou zjistit, že nelze vytvořit kombinaci jádro+initramfs, která by fungovala. Také se doufá, že dracut pomůže urychlit proces bootování použitím udev, jak to říká Jeremy:
Protože je initramfs tak důležitý v počátečních fázích bootu - a tím obtížně laditelný, když nastanou problémy - vznikly obavy z toho, že se bude začínat odznova. Není tedy překvapující, že se objevil nějaký odpor vůči zahození roků těžce nabytých zkušeností, které jsou zabudovány v různých distribučních způsobech práce s initramfs, což Maximiliana Attemse vedlo k otázce:
To je otázka, která je pokládána často, Davy na ni ale má odpověď:
Minimálně lidé od Red Hatu tedy pracují s dracutem. Davy nedávno ve svém blogu zaslal hlášení, které shrnulo, co funguje a co je potřeba udělat. I když je to fedorocentrické a několik předpokladů je natvrdo zadrátováno, takže to pravděpodobně zhavaruje na ostatních distrech, opravování je zjevně vysoko na seznamu priorit. Hlášení znamená snahu seznámit s projektem lidi, aby ho mohly začít zkoušet i ostatní distribuce. Davy navíc plánuje začít testování na jiných distribucích sám.
Ve své současné podobě je dracut vcelku minimalistický. Obsahuje skript pojmenovaný dracut, který vygeneruje zagzipovaný cpio soubor pro obraz initramfs, stejně jako shellový skript init, který v tomto obrazu skončí. Davy říká, že init toho zvládne hodně vzhledem ke svým 119 řádkům: nastaví uzly zařízení, nastartuje udev, počká na to, až se objeví kořenové zařízení, a připojí ho, připojí /proc a /sys a další. Jestliže se během tohoto procesu cokoliv pokazí, init spadne do shellu, který umožní diagnózu problému. Zatím podporuje pouze jednodušší případy, co se umístění kořenového souborového systému týče:
Zbývá pouze jediná překážka, která brání zbavit se nikým neoplakávaného nash, a to je utilita, která by zajistila switch_root (tj. přepnutí do nového kořenového adresáře a spuštění init odtud). V plánu je napsat samostatný nástroj, který by byl přidán do balíku util-linux. Prostředí poskytnuté initramfs by obsahovalo util-linux, bash a používalo glibc, což některým lidem od embedded zařízení příliš nesedlo - ti obecně preferují staticky linkované prostředí busybox. Kay Sievers shrnul důvody pro standardní prostředí:
Zbývá toho udělat spousta, aby se z dracutu stal skutečný nástroj pro vytváření obrazů initramfs - přinejmenším takových, které by fungovaly víc než jenom na Fedoře - je potřeba řešit více typů kořenových souborových systémů, je potřeba rozpoznat a reagovat na signatury hibernace, pravidla pro udev je nutné pročistit, je potřeba podporovat obrazy kdump atd. Hlavní otázka ale je: začnou na dracutu pracovat i další distribuce? Pokud Davy (nebo ostatní) dostanou věci do takového stavu, aby dracut alespoň kulhal s Debianem/Ubuntu a/nebo SUSE, přidají se na palubu i tyto distribuce? Zatím není moc důkazů o tom, že by na dracutu pracoval někdo jiný než Red Hat.
V plánu je nicméně nakonec dracut zaslat do hlavní řady jádra, aby make initramfs fungovalo na standardním jaderném stromě. Zdálo by se, že mnoho jaderných vývojářů vidí potřebu standardizace initramfs a i jeho začlenění do jádra, jak poznamenává Ted Ts'o:
Nikdo není příliš šťastný ze ztráty své konkrétní verze nástrojů pro vytváření initramfs - i kdyby jenom kvůli tomu, že je na ně zvyklý - ale standardizované řešení je věc, jejíž čas nadešel. Pravděpodobně by bylo jako výchozí bod možné použít kterýkoliv existující nástroj, ale z politických důvodů dává smysl začít odznova. V existujících nástrojích se také vyvinulo mnoho odpadu, na který by se pravděpodobně narazilo, takže jsou zde i technické důvody začít znovu. Nemělo by být překvapením, že projekt, který byl započat Red Hatem, by mohl být ve své počáteční fázi poněkud fedorocentrický, ale zjevným záměrem je distribuční agnosticismus. Zdá se, že přišel čas, kdy by se další distribuce a ostatní zájemci (například z řad embedded) měli zapojit, aby pomohli zformovat dracut do podoby užitečné pro všechny.
Jakýkoliv souborový systém navržený pro používání na rotujícím médiu musí dávat velký pozor na rozvržení souborů. Jestliže mohou být bloky souboru na zařízení uloženy sekvenčně, lze je číst a zapisovat naráz bez posouvání hlaviček během práce, které má špatný dopad na výkon. I tak se ale i těm nejopatrnějším souborovým systémům občas nezdaří rozvrhnout soubory do minimálního počtu spojitých rozsahů [extent]. Když například soubor roste a bloky těsně za předchozím koncem souboru nejsou k dispozici, souborový systém nemá jinou možnost, než umístit nové bloky někde jinde. Podle toho, jak moc je souborový systém zaplněn, mohou tyto bloky skončit opravdu daleko a tento druh fragmentace může vést k tomu, že se souborové systémy postupem času zpomalí.
Problémy s fragmentací lze napravit. Nejzjevnější způsob, jak defragmentovat disk, je vytvořit na něm nový souborový systém; konec konců, prázdné souborové systémy s fragmentací problémy nemívají. Nový souborový systém ale bude méně fragmentován, i když je na něm obnoven jeho starý obsah. Když je konečná velikost každého souboru známa dopředu, je relativně jednoduché dospět ke správným rozhodnutím o jejich rozvržení. Správci systémů toto ví a cyklus záloha-obnovení používali po mnoho let jako způsob, jak pročistit příliš fragmentovaný disk.
Tento přístup má samozřejmě problém, který je ještě větší, než riziko toho, že člověk zjistí, že jeho záloha není tak dobrá, jak si myslel. Výpadek spojený s přepisováním disku může být pro uživatele nevítaný; souborový systém, který je odpojen, reaguje ještě pomaleji než souborový systém s problémy s fragmentací. Bylo by tedy hezké mít způsob, jak defragmentovat souborový systém a přitom ho mít stále připojen a k dispozici. Tato defragmentace za běhu [online defragmentation] byla v seznamu "plánovaných vlastností" ext4 po dlouhou dobu; v tuto chvíli je to v podstatě jediná plánovaná vlastnost, která ještě nebyla začleněna do hlavní řady.
V minulosti došlo k několika pokusům o defragmentaci za běhu, ale ještě se nedostaly přes revize. Akira Fujita nyní přišel s novým patchem defragmentace ext4 za běhu, který by se díky jinému pohledu na problém mohl do hlavní řady dostat. Předchozí pokusy znamenaly rozhraní, ve kterém by aplikace v uživatelském prostoru mohla požádat souborový systém, aby defragmentoval konkrétní soubor tak, že pro něj alokuje nové (spojité) bloky. Ukázalo se, že to znamená naložit jádru příliš mnoho práce; s tímto patchem Akira vytvořil rozhraní, které přesouvá část této práce do uživatelského prostoru.
V novém schématu defragmentační démon v uživatelském prostoru vybere soubor, který je podle jeho mínění příliš rozprostřen na disku. Démon potom začne s vytvářením nového, méně fragmentovaného souboru, kterým by ten původní nahradil. Provádí se to vytvořením nového dočasného souboru na stejném souborovém systému, potom jeho vymazáním [unlink] (s tím, že popisovač je stále otevřen). Potom lze použít volání fallocate(), které do nového souboru přidá potřebný počet bloků. Jakmile má nový soubor správnou velikost, může démon použít ioctl() FS_IOC_FIEMAP, aby zjistil, z kolika rozsahů (fragmentů) se tento soubor skládá. Jestliže nový soubor neznamená oproti původnímu zlepšení, démon by ho měl prostě zavřít a vzdát se; souborový systém prostě nemá dostatečné množství spojitého místa.
V tomto bodě by démon mohl jednoduše zkopírovat starý soubor do nového a potom umístit nově defragmentovanou verzi na místo starého. Problémy s tímto přístupem zahrnují výkonnost (všechna data musí být kopírována přes uživatelský prostor) a robustnost. Jestliže jiný proces změní soubor během kopírování, nový soubor může tyto změny ztratit. A skutečně - pokud má nějaký proces starý soubor otevřený, nemusí si vůbec všimnout, že dochází k výměně. Je tedy potřeba něco chytřejšího.
Akirův patch tyto problémy řeší vytvořením nového, kouzelného ioctl volání pro ext4. Defragmentující aplikace musí vyplnit strukturu jako:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
struct move_extent {
int org_fd; /* původní popisovač souboru */
int dest_fd; /* cílový popisovač souboru */
ext4_lblk_t start; /* logický offset org_fd a dest_fd*/
ext4_lblk_t len; /* délka měněného bloku */
};
Tato struktura, když je předána novému ioctl() EXT4_IOC_DEFRAG, vyjadřuje požadavek, že má jádro přesunout len bloků z původního souboru počínaje pozicí start. V podstatě zkopíruje data odpovídající rozsahu do (kompletně alokovaného a hezky spojitého) prostoru v novém souboru a potom provede kouzelné prohození bloků. Tyto spojité bloky z nového souboru jsou patchovány do starého souboru, zatímco fragmentované bloky jsou naopak vloženy do nového souboru. Jakmile je tímto způsobem ošetřen celý soubor, je defragmentován, aniž by se viditelně cokoliv přesunulo.
Posledním krokem je smazání "nového" souboru, který nyní obsahuje bloky "starého" souboru. Vzhledem k tomu, že soubor byl smazán, souborový systém si vezme staré bloky zpátky poté, co je úloha dokončena. Pro zvědavce Akira zaslal zdrojový kód pro defragmentační nástroj v uživatelském prostoru, který ukazuje, jak toto rozhraní použít.
Proti novému kódu nebylo mnoho námitek. Chris Mason podotkl, že systém provede nehezké věci, pokud se změní rozvržení swapovacího souboru. O tomto problému zjevně přemýšlel - v takovém rozsahu, že:
Krom toho jsou zde nějaké menší záležitosti, jako je definice ABI v typech jako int místo na architektuře nezávislých typech. Byla požadována oddělená čísla bloků pro zdroj a cíl; tato vlastnost by pomohla vývojářům pracujícím na systémech s hierarchickým ukládáním. Možnost řídit alokaci bloků by byla užitečná v situacích, kde lze vylepšit výkonnost seskupením souvisejících souborů na disku.
Také by mohlo mít cenu najít způsob, jak přesunout většinu této funkce do vrstvy VFS, kde by ji mohly použít i další souborové systémy; to by se ale mohlo ukázat jako složitý úkol a správce ext4 Ted Ts'o příliš netouží to zkoušet.
Přes tyto menší záležitosti se zdá, že se ext4 blíží k přidání tolik žádané vlastnosti defragmentace zaživa.
Originál tohoto článku napsal Goldwyn Rodrigues.
Při zoufalém nedostatku paměti se nastartuje zabiják při nedostatku paměti [out-of-memory (OOM) killer] a použitím sady heuristik, které se během doby vyvíjely, vybere proces, který zabije. To může být protivné uživatelům, kteří by možná chtěli, aby byl zabit jiný proces. Zabitý proces také může být z hlediska systému důležitý. Mnoho vývojářů má pocit, že je potřeba větší kontrola nad aktivitami OOM zabijáka, abychom se vyhnuli předčasnému zesnutí špatných procesů.
Jádra hlavních distribucí nastavují výchozí hodnotu /proc/sys/vm/overcommit_memory na nulu, což znamená, že procesy mohou požadovat víc paměti, než je v současnosti v systému volné. To se dělá na základě heuristiky, že alokovaná paměť se nepoužívá okamžitě a že procesy během svého života nespotřebují veškerou paměť, kterou alokují. Bez přetěžování [overcommit] systém plně nevyužije svou paměť a částí se tedy bude plýtvat. Přetěžování paměti dovolí systému používat ji efektivněji, ale může vést k OOM situacím. Na paměť náročné programy mohou paměť systému vyčerpat, takže se zadrhne a zastaví. Může to vést k situaci, kdy je tak málo paměti, že uživatelskému procesu nelze alokovat ani jedinou stránku, takže správce nemůže zabít vhodnou úlohu, a že jádro nemůže provést důležité úkoly, jako je uvolnění paměti. V takové situaci naskočí OOM zabiják a vybere proces, který se stane obětním beránkem pro dobro zbytku systému.
Uživatelé a správci systému často žádali o způsoby, jakými řídit chování OOM zabijáka. Proto byl zaveden řídící prvek /proc/<pid>/oom_adj, kterým lze zachránit důležité procesy před zabitím a definovat pořadí zabíjení procesů. Přípustné hodnoty oom_adj jsou v rozsahu -17 až +15. Čím vyšší skóre, tím pravděpodobněji bude s ním spojený proces zabit OOM zabijákem. Jestliže je oom_adj nastaveno na -17, proces je OOM zabijákem ignorován.
Proces, který má být zabit v situaci, kdy je nedostatek paměti, je vybrán podle své špatnosti [badness]. Špatnost je zobrazena v /proc/<pid>/oom_score. Tato hodnota je určena na základě toho, že systém ztrácí minimum udělané práce, získá velké množství paměti, nezabije nevinný proces spotřebovávající hodně paměti a zabije minimální počet procesů (pokud možno pouze jeden). Špatnost procesu se počítá z původní velikosti paměti, času CPU (utime + stime), doby běhu (uptime - start time) a hodnoty oom_adj. Čím více paměti proces spotřebovává, tím vyšší skóre. Čím déle je proces v systému naživu, tím menší skóre.
Jakýkoliv dostatečně nešťastný proces, který je právě v systémovém volání swapoff() (které odstraňuje odkládací soubor ze systému), je k zabití vybrán jako první. Pro ty ostatní se počáteční velikost paměti stane základním skóre špatnosti procesu. Polovina paměti spotřebované potomky je přidána ke skóre rodiče, pokud nesdílí stejnou paměť. Forkující servery jsou tedy prvními kandidáty na zabití. Pokud má rodič pouze jedno "hladové" dítě, je potomek preferován před rodičem. Nakonec je aplikována následující heuristika, aby se zachránily důležité procesy:
Jestliže má úloha hodnotu nice vyšší než nula, její skóre se zdvojnásobuje.
Procesům superuživatele nebo úlohám s přímým přístupem k hardwaru (CAP_SYS_ADMIN, CAP_SYS_RESOURCE nebo CAP_SYS_RAWIO) se skóre dělí 4. Tento krok je kumulovatelný, tzn. úloze superuživatele, která má přímý přístup k hardwaru, se skóre dělí 16.
Jestliže se stav nedostatku paměti stal na jedné sadě cpu [cpuset], ale kontrolovaná úloha do této sady nepatří, její skóre se dělí 8.
Výsledné skóre je násobeno oom_adj-tou mocninou dvou (tj. body <<= oom_adj, když je kladné, a body >>= 
oom_adj), když ne).
Poté je vybrána úloha s nejvyšším skóre a její potomci zabiti. Proces sám bude zabit v případě, že nemá potomky.
/proc/<pid>/oom_score je dynamická hodnota, která se během času mění a není flexibilní podle rozdílných a dynamických politik, které potřebuje správce systému. Je obtížné odhadnout, který proces bude v případě OOM situace zabit. Správce musí přenastavit skóre pro každý vytvořený proces a pro každý proces, který skončí. To může být na systému s rychle vytvářenými procesy poměrně obtížné. Aby se pokusil zjednodušit implementaci politiky OOM zabijáka, navrhl Jevgenij Poljakov na jménech založené řešení. S jeho patchem je proces, který má zemřít první, ten, který spustil program, jehož jméno je v /proc/sys/vm/oom_victim. Na jménech založené řešení má ale svá omezení:
Jméno úlohy není spolehlivý indikátor skutečného jména a je v poli jména procesu zkráceno. Krom toho s různě pojmenovanými symlinky na spustitelné binární soubory to nebude fungovat.
Tento přístup umožňuje specifikovat pouze jedno jméno, čímž vylučuje možnost vytvoření hierarchie.
Může běžet několik procesů stejného jména, ale z jiného binárního souboru.
Chování se nijak nemění od současné výchozí implementace, pokud neexistuje proces žádného jména, které je definováno v /proc/sys/vm/oom_victim. Zvyšuje to počet hledání, která jsou potřeba k nalezení oběti.
Alanu Coxovi se toto řešení nelíbilo, naznačil, že nejvhodnějším způsobem, jak přistoupit k problému, jsou kontejnery. Jako reakci na tento návrh zaslal Nikanth Karthikesan oom_killer controller, který poskytuje možnost řízení sekvence procesů, které mají být zabity, když systému dojde paměť. Patch zavádí kontrolní skupinu (cgroup) OOM s polem oom.priority. Proces, který má být zabit, je vybrán ze seznamu procesů, které mají nejvyšší hodnotu oom.priority.
Pro převzetí kontroly nad OOM zabijákem je potřeba připojit pseudosouborový systém OOM zavedený patchem:
# mount -t cgroup -o oom oom /mnt/oom-killer
Adresář OOM zabijáka obsahuje seznam všech procesů v souboru tasks a jejich OOM prioritu v oom.priority. Ve výchozím stavu je oom.priority nastaveno na jedna.
Když chcete vytvořit zvláštní kontrolní skupinu obsahující seznam procesů, které by jako první měly být středem pozornosti OOM zabijáka, vytvořte pod /mnt/oom-killer adresář, který je bude reprezentovat:
# mkdir beranci
Nastavte hodnotu oom.priority na dostatečně vysokou hodnotu:
# echo 256 > /mnt/oom-killer/beranci/oom.priority
oom.priority je 64bitový unsigned integer a může obsahovat maximální hodnotu, kterou takové číslo může držet. Když hledá procesy, které mají být zabity, vybírá OOM zabiják proces ze seznamu úloh s nejvyšší hodnotou oom.priority.
PID procesu lze přidat do seznamu úloh takto:
# echo <pid> > /mnt/oom-killer/beranci/tasks
Pokud chcete vytvořit seznam procesů, které OOM zabijákem nebudou zabity, vytvořte adresář, který bude obsahovat jejich seznam:
# mkdir neznicitelni
Nastavení oom.priority na nulu vyjme všechny procesy v této kontrolní skupině ze seznamu cílů k zabití.
# echo 0 > /mnt/oom-killer/neznicitelni/oom.priority
Více procesů lze do této skupiny přidat zapsáním jejich pid do seznamu úloh nezničitelné skupiny:
# echo <pid> > /mnt/oom-killer/neznicitelni/tasks
Důležité procesy jako databáze a jejich řízení lze přidat do této skupiny, takže je OOM zabiják bude ignorovat, když hledá procesy k zabití. Všichni potomci procesu v seznamu jsou automaticky přidáni do stejné kontrolní skupiny a dědí oom.priority rodiče. Když má několik úloh stejnou nejvyšší hodnotu oom.priority, OOM zabiják vybere proces podle oom_score a oom_adj.
Tento přístup se ale nelíbí uživatelům sad CPU [cpusets]. Uvažme dvě sady CPU, A a B. Jestliže proces v sadě CPU A má vysokou hodnotu oom.priority, bude zabit, když sadě CPU B dojde paměť, i když sada CPU A jí má dost. Kvůli tomu je potřeba jiný návrh, jak zkrotit OOM zabijáka.
Zajímavým výsledkem diskuze bylo řešení OOM situací v uživatelském prostoru. Jádro zašle upozornění do uživatelského prostoru a aplikace zareagují zahozením svých cache v uživatelském prostoru. V případě, že procesy v uživatelském prostoru nejsou schopny uvolnit dostatek paměti nebo požadavek jádra na uvolnění paměti ignorují, jádro se uchýlí ke staré dobré metodě zabijení procesů. mem_notify, které vyvinul Kosaki Motohiro, je jeden takový pokus z minulosti. Patch mem_notify nicméně nelze aplikovat na verze jádra po 2.6.28, protože se změnil postup znovuzískávání paměti ve správě paměti, ale návrhové principy a cíle lze převzít. David Rientjes navrhuje mít jedno nebo dvě hybridní řešení:
Většina vývojářů preferuje udělat z /dev/mem_notify klienta kontrolních skupin. To lze dále rozšířit začleněním navrhovaného oom-řadiče [oom-controller].
Vývojáři Androidu potřebovali větší stupeň kontroly nad situacemi, kdy je nedostatek paměti, protože OOM zabiják nenastartuje, dokud není hodně pozdě v takové situaci, tj. dokud nejsou prázdné všechny cache. Android chtěl řešení, které by se spustilo brzy v případě, že dochází volná paměť. Proto zavedli ovladač "lowmemory", který má pro nedostatek paměti několik hranic. V situaci, kdy je nedostatek paměti a jsou splněny podmínky pro první hranici, na problém jsou upozorněny procesy na pozadí. Neukončují se, ale uloží svůj stav. To ovlivňuje zpoždění při přepínání aplikací, protože aplikace se musí při aktivaci znovu nahrát. Při dalším tlaku lowmemory zabiják zabije nekritické procesy na pozadí, jejichž stav byl uložen při předchozí hranici a nakonec jsou zabíjeny i procesy v popředí.
Několik spouštěčů [triggers] dává procesům dostatek času uvolnit své cache, protože v OOM situaci nemusí být procesy v uživatelském prostoru vůbec schopné běžet. Může stačit jediná alokace interních struktur jádra nebo výpadek stránky a systému dojde paměť. Předběžné upozornění na situaci nedostatku paměti může předejít vzniku situace, kdy paměť úplně dojde, tak, že aplikace v uživatelském prostoru zareagují na dané upozornění.
Zabíjení procesů založené na heuristice jádra není optimální řešení a tyto nové snahy nabídnout lepší kontrolu uživateli, aby mohl vybrat proces, který se stane obětním beránkem, jsou kroky k robustnímu návrhu, který dává větší možnosti řízení do rukou uživateli. Může nicméně nějaký čas trvat, než vznikne konsenzus o tom, jak bude konečné řešení vypadat.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
pokud není v textu vloženo logo jako obrázek, ale je tam název napsán, držel bych se pravidel pravopisu a psal velké písmeno.Nejde o žádné logo, všechno byl text - velké či malé D je v daném místě podle toho, jak to bylo v originálu.
Jak to bylo v originále s velikostí písmen není pro překlad moc podstatné, protože angličtina má pravidla pro psaní velkých písmen určitě odlišná od češtiny.Což to jo, ale pokud vím, tak v angličtině se velké písmeno vyskytuje častěji než v češtině (např. V Názvu Všechna Velká), takže když už tam bylo malé, nechal jsem to tak. (Jestli k tomu byl nějaký důvod nebo autor psal, jak mu to přišlo pod ruku, to nevím)
6.3.2009 19:05
Jardík | skóre: 40
| blog: jarda_bloguje
#define insert(list1, list2) \
do { \
list2->next = list1->next; \
list1->next->prev = list2; \
list2->prev = list1; \
list1->next = list2; \
} while (0)
Smysl toho cyklu se mi nějak vytrácí ...
Je to nejspis zpusob jak se vyporadat s tim, ze to vypada jako jeden statement a uzivatel by za to chtel napsat strednik, coz vadi kdyz se to napise pred else. Slozenou zavorkou se cely prikaz uzavre jakoby tam strednik uz byl a tohle je zpusob jak udelat blok, ktery se strednikem uzavrit musi a pak to vypada hezky a uzivatel nemusi resit, ze to je makro.
6.3.2009 21:45
Jardík | skóre: 40
| blog: jarda_bloguje
7.3.2009 11:01
Jardík | skóre: 40
| blog: jarda_bloguje
Samozřejmě, že vypustí (a to dokonce i pro úrověň optimalizace -O0). Výsledek překladu typu nahraj nulu do registru, nahraj nulu do dalšího registru, porovnej registry a skoč při neshodě na začátek (či nějak podobně) by byl opravdu dost hloupý.
Kde je popis k POHMELFS? Inak som pozreal na googli a zda sa za randomread nema taky dobry ako NFS, v ostatnych testoch ho predbieha.
Podla mna by mal byt dracut flexibilnejsi, nemyslim si ze bash sa bude pacit napriklad vyvojarom z Ubuntu, ktori na vsetky systemove scripty pouzivaju /bin/sh ktory je v skutocnosti dash. Ale napad je to ozaj dobry a dufam ze sa ostatni pripoja.