Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Nový CEO Mozilla Corporation Anthony Enzor-DeMeo tento týden prohlásil, že by se Firefox měl vyvinout v moderní AI prohlížeč. Po bouřlivých diskusích na redditu ujistil, že v nastavení Firefoxu bude existovat volba pro zakázání všech AI funkcí.
Současné vývojové jádro je 2.6.34-rc1; během minulého týdne nebyly vydány žádné nové předverze.
Stabilní aktualizace: 15. března byla vydána jádra 2.6.32.10 a 2.6.33.1, se 145 a 123 patchi jsou obě obrovská.
-- Ingo Molnár
-- Eric Sandeen
napsal Jonathan Corbet, 16. března 2010
Na konci vývojového cyklu 2.6.33 Linus naznačil, že příští začleňovací okno bude o něco kratší než obvykle. A 2.6.34-rc1 opravdu vyšlo 8. března, dvanáct dní po vydání 2.6.33. Mnoho stromů zůstalo kvůli této změně na mraze a zdá se, že to Linusovi vyhovuje.
I tak byly některé stromy přetaženy po vydání -rc1. Mezi ně patří strom trivial s obvyklým nákladem oprav pravopisu a dalšími malými změnami. Také se objevila velká sada změn v ARM, včetně podpory pro mnoho nových desek a zařízení. Řadič využívání paměti získal novou vlastnost pro práh [threshold], což umožňuje jemnější řízení a získávání informací o využívání paměti. A tak dál, celkem bylo (v době psaní tohoto článku) od vydání 2.6.34-rc1 začleněno 1000 změn.
Když se ale objevil poslední požadavek na přetažení SCSI, Linus v ten okamžik nakreslil čáru do písku. Linuse, jak se zdá, trochu unavuje to, co u některých správců subsystémů považuje za jednání na poslední chvíli.
Linus tedy říká, že má v plánu být v budoucnu ještě méně předvídatelný. Determinismus v této fázi vývojového procesu evidentně vede k chování, které nemá rád, takže v budoucnu vývojáři nebudou schopni říci, jak dlouhé začleňovací okno bude. V takovém prostředí většina správců subsystémů bude pracovat tak, jako by začleňovací okno bylo zkráceno na jediný týden – což byl nápad, který byl diskutován a odmítnut na Jaderném summitu 2009.
napsal Jonathan Corbet, 16. března 2010
Na patchích škálovatelnosti VFS Nick Piggin už pracuje nějaký ten pátek – což je pro nízkoúrovňovou práci zaměřenou na výkon běžné. Nedávno Nick začal patch dělit na menší části, přičemž každá z nich řeší jednu část problému a každou z nich lze zvažovat samostatně. Jeden z těchto kousků zavádí zajímavý mechanismus pro vzájemné vyloučení nazvaný velký čtenářský zámek [big reader lock] či „brzámek“ [brlock].
Těm, kteří si patch přečtou, budiž odpuštěno, když nebudou chápat, o co jde; cokoliv, co kombinuje záludné zamykání a třicetiřádková makra pro preprocessor, způsobuje vrásky na čele. Základní koncept je ale jednoduchý: Brzámek se snaží zajistit, aby zamykání pouze pro čtení bylo tak rychlé, jak to jenom jde, tak, že vytvoří pole spinlocků, pro každé CPU jeden. Kdykoliv CPU potřebuje získat zámek pouze pro čtení, zabere vlastní zámek. Zamykání pro čtení je tedy lokální pro CPU a neobjevuje se žádné odrážení řádku cache [cache line bouncing]. A vzhledem k tomu, že soupeření o spinlock specifický pro CPU by ve skutečnosti mělo být nulové, tento zámek bude rychlý.
Život je o trochu ošklivější, když je potřeba získat zámek pro přístup pro zápis. Ve zkratce: Nešťastné CPU musí projít celé pole a získat spinlock všech CPU. Na 64procesorovém systému je tedy potřeba získat 64 zámků. To rychlé nebude ani v případě, že se o žádný zámek nebude soupeřit. Tento typ zámku by se tedy měl používat zřídka a jenom v případech, kdy téměř zcela převažuje přístup pro čtení.
Jeden takový případ – cíl tohoto zámku – je vfsmount_lock, který je vyžadován (pro čtení) při vyhledávání cest [pathname lookup]. Tato vyhledávání jsou častá a zjevně kritická pro výkonnost. Na druhou stranu je přístup pro zápis potřeba pouze v případě, kdy se připojuje nebo odpojuje souborový systém – což se děje mnohem méně často. Brzámek se sem tedy velmi dobře hodí a jeden (z mnoha) malých kousků puzzle škálovatelnosti VFS je na místě.
napsal Jonathan Corbet, 16. března 2010
Mezi běžná pravidla jádra patří to, že se snaží vyhnout spotřebování většího množství zdrojů, než je nezbytně nutné; systémový čas je lépe využíván programy v uživatelském prostoru. Patch pro zabrání CPU Tejuna Heo je tedy možná trochu překvapující; vytváří mechanismus, kterým si jádro může vyhradit monopol na jedno či více CPU a spustit na něm nicnedělající proces o vysoké prioritě. Tato sada patchů má ale dobré odůvodnění; a dokonce může v některých situacích vylepšit výkonnost.
Předpokládejme, že chceme zabrat jedno nebo více CPU v systému. První krok je vytvoření zabírací [hogging] funkce:
#include <linux/cpuhog.h> typedef int (*cpuhog_fn_t)(void *arg);
Když přijde čas na zabírání, je tato funkce zavolána s nejvyšší možnou prioritou. Jestliže je cílem opravdu CPU zabrat, tato funkce by pravděpodobně měla běžet v těsné smyčce. Je ale potřeba zajistit, aby tato smyčka mohla někdy skončit; nikdo pravděpodobně nebude chtít vyřadit CPU navždy.
Zabrání procesoru se provádí jednou z funkcí:
int hog_one_cpu(unsigned int cpu, cpuhog_fn_t fn, void *arg);
void hog_one_cpu_nowait(unsigned int cpu, cpuhog_fn_t fn, void *arg,
struct cpuhog_work *work_buf);
int hog_cpus(const struct cpumask *cpumask, cpuhog_fn_t fn, void *arg);
int try_hog_cpus(const struct cpumask *cpumask, cpuhog_fn_t fn, void *arg);
Volání hog_one_cpu() způsobí, že se daná fn() spustí na cpu v režimu kompletního zabrání; volající proces bude čekat, než se fn() vrátí; v tu chvíli je předána návratová hodnota fn(). Pokud je potřeba zároveň s tím dělat nějakou užitečnou práci (na jiném CPU), je potřeba použít hog_one_cpu_nowait(); vrátí se okamžitě, přičemž fn() může v tom okamžiku ještě běžet. Strukturu work_buf musí alokovat volající a nepoužívat ji, o víc se ale volající starat nemusí.
Někdy není úplná kontrola nad jedním CPU dostačující; v takovém případě lze volat hog_cpus(), která spustí fn() naráz na všech CPU stanovených cpumask. Varianta try_hog_cpus() je podobná, ale na rozdíl od hog_cpus() nečeká, pokud někdo zabral CPU před ní.
K čemu by tento mechanismus tedy mohl být? Jedna možnost je stop_machine(), která se volá, aby se zajistilo, že se v systému chvíli nebude vůbec nic dít. stop_machine() se obvykle volá, když v systému probíhají zásadní změny – například jsou vkládány dynamické sondy, nahrávány jaderné moduly nebo odstraňována CPU. To vždy fungovalo stejným způsobem jako funkce pro zabrání CPU – spuštěním vlákna o vysoké prioritě na každém procesoru.
Nová implementace stop_machine() přirozeně používá hog_cpus(). Na rozdíl od předchozí implementace (která využívala pracovní fronty) nový kód využívá vlákna pro zabírání CPU, která již existují. To odstraňuje výkonnostní bug, který nahlásil Dimitri Sivanich, kde je množství času potřebného pro boot systému zdvojnásobeno kvůli režii různých volání stop_machine().
Další využití je vynucení toho, aby každé CPU rychle prošlo plánovačem; to může být užitečné, pokud chce systém vynutit přechod do nového ochranného období [grace period] při čtení-kopírování-zápisu. Dříve byla tato úloha poněkud podivným způsobem zabudována do vlákna migration, které již nyní běží na každém CPU jedno; nyní se používá přímočaré volání pro zabrání CPU.
Vlákno migration je samo o sobě také uživatelem funkce pro zabrání jednoho CPU. Toto vlákno přichází ke slovu, když chce systém přestěhovat proces běžící na daném CPU. První věc, kterou je potřeba udělat, je vysídlit tento proces z CPU – úkol, pro který se zabírání CPU dobře hodí. Jakmile zabírací funkce CPU převezme, právě vystěhovaný proces lze přestěhovat do nového domova.
Konečným výsledkem je odstranění slušného množství kódu, pročištění implementace vlákna migration a zlepšení výkonnosti stop_machine(). Objevily se obavy, že pokud by jako zabírající funkce byla předána funkce, která blokuje, mohlo by to v některých situacích způsobit problémy. Blokování při zabírání CPU se ale zdá být z principu kontradikce; lze očekávat, že obvyklá reakce bude „to nedělej“. A druhá verze patche dokonce zakazuje v zabíracích funkcích spát. Reakce „to nedělej“ bude samozřejmě i odpověď na většinu použití zabírání CPU obecně; zabírání procesorů v jádře je stále ve většině případů považováno za nespolečenské.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Nevidel by jste rozdeleni partici. Leda ze by se radic prepl do no-raid modu, a nabizel by vam disky naprimo, ale zde by opet nebyl zadny viditelny oddil, pouze veeeelky disk.
Hodte sem dmesg z beziciho jadra, a pak config z Vaseho noveho. Takto by jsme mohli zvazovat moznosti do nekonecna