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.
Okno pro začleňování do 2.6.25 je (6. 2.) stále otevřené, takže v rámci tohoto vývojového cyklu ještě nevyšly žádné předverze. Do hlavního repozitáře proudí nové patche - zatím jich bylo asi 7500.
Aktuální -mm strom je 2.6.24-mm1. V poslední době bylo vynecháno několik stromů subsystémů, aby se vyřešily konflikty, a spousta patchů byla převedena do hlavní větve.
Starší jádra: 2.6.22.17 vyšlo 6. února a obsahuje poměrně dost oprav. Je nepravděpodobné, že by šlo o poslední vydání v rámci 2.6.22.x.
Nemyslím, že bychom měli problém s debugováním zaměřeným na vývojáře. Daleko více by mě zajímala infrastruktura, která by pomohla obyčejným uživatelům posílat lepší hlášení o chybách. A to kgdb není ani vzdáleně.
-- Linus Torvalds stále není přesvědčen o potřebnosti jaderných debuggerů.
Používal jsem kgdb průběžně 4 - 5 let, dokud nepřestal fungovat. Neřekl bych, že by se mi někdy hodil pro vlastní debugování, spíše pro pozorování dění v jádře.
Od minulého týdne bylo do hlavního git repozitáře zařazeno dalších 3800 sad změn. Následuje přehled těch zajímavějších. Nejprve ty viditelné pro uživatele:
Změny viditelné vývojáři jádra:
x86 má novou sadu funkcí pro snadnou manipulaci s atributy stránek:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
set_memory_uc(unsigned long addr, int numpages); /* nekešované */
set_memory_wb(unsigned long addr, int numpages); /* kešované */
set_memory_x(unsigned long addr, int numpages); /* spustitelné */
set_memory_nx(unsigned long addr, int numpages); /* nespustitelné */
set_memory_ro(unsigned long addr, int numpages); /* pouze pro čtení */
set_memory_rw(unsigned long addr, int numpages); /* čtení-zápis */
Přibyly také funkce set_pages_*, které berou ukazatel struct page místo počáteční adresy.
API časovačů s vysokým rozlišením bylo doplněno o:
unsigned long hrtimer_forward_now(struct hrtimer *timer,
ktime_t interval);
Přesune vypršení daného časovače dopředu před aktuální čas určený přiřazenými hodinami.
Struktura device nyní drží ukazatel na strukturu device_dma_parameters:
struct device_dma_parameters {
unsigned int max_segment_size;
unsigned long segment_boundary_mask;
};
Tyto parametry používá mapovací vrstva DMA (a především mapovací kód IOMMU), aby zajistila, že budou I/O operace provedeny v rámci dosahu zařízení. PCI vrstva funkci podporuje dvěma novými funkcemi:
int pci_set_dma_max_seg_size(struct pci_dev *dev, unsigned int size);
int pci_set_dma_seg_boundary(struct pci_dev *dev, unsigned long mask);
Ovladače zařízení s nezvykle striktními omezeními DMA by tuto funkci pravděpodobně měly používat, aby bylo jisté, že budou daná omezení respektována.
Jedna z věcí, které se do 2.6.25 nedostaly, je debugger KGDB pro architekturu x86. Vtipné bylo, že když se na jedné z mini-konferencí v rámci linux.conf.au diskutovalo o "propašování" KGDB za Linusovými zády, trvalo docela dlouho, než si účastníci všimli, že Linus stojí vzadu v místnosti a všechno poslouchá. Linus stále trvá na tom, že KGDB nezačlení jako součást stromu x86 a celkově ho ta myšlenka moc nebere.
V tuto chvíli je okno pro začleňování stále otevřené a možná tak zůstane ještě další týden, takže se možná dočkáme dalšího zajímavého kódu.
Špatný výkon NFS (Network File System) je častým předmětem stížností. Kromě toho má NFS závažné chyby jak z pohledu vývojářů, tak uživatelů a chová se výrazně jinak než lokální souborové systémy. Oba tyto problémy jsou podnětem k vytváření nových síťových souborových systémů, z nichž dva byly představeny minulý týden.
Coherent Remote File System (CRFS) představil minulý týden na linux.conf.au Zach Brown z firmy Oracle. Jako úložiště na serveru používá BTRFS (anglicky vyslovováno "butter-f-s") - místo aby fungoval nad jakýmkoliv jiným POSIXovým souborovým systémem, jak to dělá NFS. Podle Browna má BTRFS několik důležitých funkcí, které převáží nepříjemnosti spojené s převodem dat na jiný souborový systém. Největší z nich je schopnost skládat operace (například vytváření nebo odlinkování souboru) atomickým a idempotentním způsobem.
CRFS používá uživatelského démona (crfsd), který komunikuje s BTRFS oddílem, a několik klientů. Klienty velmi využívají jadernou kešovací infrastrukturu pro VFS, takže jsou implementovány jako moduly. Uživatel, který si přeje přistupovat k BTRFS na serveru, jej musí připojit jako CRFS oddíl; crfsd musí mít k oddílu exkluzívní přístup. To je další odlišnost od NFS, který komunikuje s lokálními připojeními použitých souborových systémů.
Základní myšlenka CRFS je to, aby klienty kešovaly co nejvíce dat ze souborového systému, přičemž budou používány protokoly pro koherenci keše, aby se snížil objem síťového provozu, který to způsobí. Klienty udržují přehled o stavu keše pro každý objekt, který uložily, a server hlídá stav keše u všech objektů, které klienty mají.
Datové přenosy v obou směrech jsou prováděny pomocí CRFS "item ranges" [rozsahy položek]. CRFS objekty používají schéma klíčů z BTRFS k reprezentaci objektů (data souborů, adresáře, položky adresářů, inody atd.) v souborovém systému. Rozsah položky je souvislá sekce klíčového prostoru definovaná minimální a maximální hodnotou klíče, které jsou součástí zprávy. Když klient naplňuje svou keš, může požádat o konkrétní klíč, ale také může nabídnout, že vezme okolní klíče; pokud server ty klíče vidí v uzlu listu BTRFS [leaf node], může je poslat také.
Aktuální výkon CRFS je při obyčejném rozbalení taru přibližně 3× lepší než u asynchronního NFS. Srovnávání se synchronními připojeními NFS (při kterých musí každý zápis dorazit na disk) nedává smysl; mezi těmi dvěma druhy připojení je zhruba 10násobný rychlostní rozdíl. Brown na CRFS pracoval "asi rok", ale zatím neukázal kód. Do té doby jsou jediným zdrojem informací o CRFS slajdy [PDF] a video [Theora] z jeho přednášky a také několik zápisků v blogu
Další souborový systém, který by však chtěl mít větší záběr než CRFS, je Parallel Optimized Host Message Exchange Layered File System (POHMELFS), oznámil na linux-kernel Jevgenij Poljakov. POHMELFS má být stavebním kamenem pro distribuovaný souborový systém, který by nabízel víceserverovou architekturu a umožňoval operace u nepřipojených oddílů. Poljakov na něm zatím pracoval jen měsíc, takže jde o velmi raný začátek.
Vize POHMELFS je v některých ohledech podobná CRFS - hlavně v tom, že klienty budou dělat co nejvíce práce lokálně, s minimálním vstupem od uživatele. Stejně jako u CRFS komunikují klientské jaderné moduly s uživatelským démonem na serveru a používají protokoly pro koherenci keše, aby byla data a metadata synchronizována. U CRFS ještě koherence není implementována, ale do jisté míry už načrtnuta, zatímco POHMELFS má ještě dost načrtávání před sebou. Na rozdíl od CRFS podporuje POHMELFS POSIXové souborové systémy na straně serveru a kód už je k dispozici.
POHMELFS ještě musí překonat dost vážné překážky, včetně postarání se o ID souborů v samostatných souborových systémech na straně klienta, aby mohla být synchronizována se serverem. Stávající kód implementuje propisovací [write-through] verzi keše, která vytváří objekty na serveru předtím, než jsou použity v keši na straně klienta. Kromě toho je k dispozici dodatečný patch, který implementuje hack k vypnutí keše pro zpětný zápis [writeback] a použití pouze kešování na straně klienta. Není překvapení, že je to velmi rychlé, ale ne zrovna použitelné při vícerých připojeních souborového systému. Poljakov v podstatě ukazuje výhody kešování na straně klienta, ale v širším kontextu.
Bude trvat dlouho - jestli k tomu vůbec dojde - než se pozdější verze některého z těchto souborových systémů dostane do jádra. Zbývá ještě udělat hodně práce, ale stojí za to ji sledovat, abychom měli představu o tom, kam se síťové a distribuované souborové systémy ubírají. Aby byly užitečné i mimo Linux - podobně jako je všudypřítomný NFS - muselo by dojít k nějaké standardizaci a následnému přijetí velkými hráči v oboru. A to potrvá dlouho.
Spinlocky jsou nejnižší úrovní mechanismu pro vzájemné vyloučení v jádře. Jako takové mají velký vliv na bezpečnost a výkon jádra, a proto není překvapivé, že optimalizaci různých implementací spinlocků bylo věnováno velké úsilí. To však neznamená, že by bylo vše hotovo; patch začleněný do 2.6.25 ukazuje, že je stále něco na práci.
Na architektuře x86 v jádře 2.6.24 je spinlock reprezentován celočíselnou hodnotou. Hodnota 1 značí, že je zámek k dispozici. Kód funkce spin_lock() funguje tak, že snižuje hodnotu (celosystémovým atomickým způsobem) a pak hlídá, jestli výsledek není nula; pokud ano, byl zámek úspěšně získán. Je-li však výsledek snižování hodnoty záporné číslo, kód spin_lock() ví, že zámek náleží někomu jinému. Takže "zaneprázdněně čeká" [busy-wait] (spins) v uzavřené smyčce, dokud nebude hodnota kladná; pak jde zpátky na začátek a začne znovu.
Jakmile byla důležitá část kódu vykonána, uvolní držitel zámek tím, že jej nastaví na 1.
Tato implementace je velmi rychlá, zvláště v případech, když se o zámek nikdo nepřetahuje (tak by to mělo být většinou). Také je díky tomu patrné, jak špatné je pro zámek to přetahování - čím více je hodnota zámku v záporu, tím více procesorů se o něj pokouší. Ale takový přístup má jednu nevýhodu: není to fér. Jakmile je zámek uvolněn, získá ho první procesor, kterému se podaří snížit jeho hodnotu. Nelze zaručit, že ho dostane ten, který čekal nejdéle; dokonce může mít výhodu procesor, který ho právě uvolnil, protože vlastní příslušný řádek keše (pokud by se rozhodl ho znovu rychle získat).
Člověk by doufal, že neférové chování spinlocků nebude znamenat velký problém; většinou to bývá tak, že když se soupeří o zámky, tak je výkon ovlivněn už samotným soupeřením, aniž by se vůbec dostalo na férovost. Nick Piggin se však nedávno na problém podíval znovu, když si všiml, že:
Na 2soketovém Opteronu s 8 jádry je neférovost spinlocků velmi znatelná. Při testu v uživatelském prostoru trvá každému vláknu provedení dvakrát déle a některá vlákna se na řadu vůbec nedostanou, zatímco jiným je zámek "neférově" přidělen až milionkrát.
Takové rozdíly v době provádění rozhodně nejsou žádoucí. A neférovost zámků také působí problémy s latencí; těžko zaručit maximální latenci, když může být čekání na spinlock libovolně dlouhé.
Nick reagoval implementací spinlocků, kterou nazývá "ticket spinlocks". Ze spinlocku se v první verzi tohoto patche stane 16bitová veličina rozdělená na dva bajty:
_____________________________ | | | | next | owner | |______________|______________|
Každý bajt lze považovat za číslo tiketu. Jestli jste někdy byli v obchodě, kde si zákazníci berou papírové lístky, aby se zaručilo, že budou obslouženi v pořadí, ve kterém přišli, pak můžete pole "next" brát jako číslo na dalším lístku v pořadí, zatímco "owner" je číslo, které zrovna svítí na displeji u přepážky.
S novým schématem je tedy hodnota zámku inicializována na nulu (obě pole). spin_lock() začne tím, že si poznamená číslo zámku a pak zvýší hodnotu pole "next" - vše v jediné atomické operaci. Je-li hodnota "next" (před zvýšením) rovna hodnotě "owner", byl zámek získán a je možné pokračovat v práci. Jinak bude procesor čekat, dokud nebude "owner" zvýšen na správnou hodnotu. Tím pádem je k uvolnění zámku potřeba pouze zvýšit hodnotu "owner".
Výše popsaná implementace má jednu menší nevýhodu v tom, že omezuje počet procesorů na 256 - při vyšším počtu by mohl velmi žádaný zámek způsobit, že by si více procesorů myslelo, že mají na lístku stejné číslo. Není nutno říkat, že z toho pramenící zmatky není možné tolerovat. Omezení na 256 procesorů není vítané především tam, kde už se teď pracuje se systémy o více procesorech. Takže doplňkový "big ticket" patch - rovněž začleněný do 2.6.25 - používá 16bitové hodnoty, je-li nakonfigurovaný maximální počet procesorů vyšší než 256. To zvyšuje maximální počet na 65536, což už by mohlo stačit.
Se starou implementací spinlocků procesory soupeřily o to, který z nich dokáže zámek popadnout rychleji. Nyní spořádaně čekají, až na ně dojde řada podle toho, kdy se o zámek přihlásily. Časy provádění při více vláknech se urovnaly a maximální latence byly sníženy (a především je možné je zjistit). Nová implementace má podle Nicka mírnou režii, ale na současných procesorech je velmi malá a v poměru k režii selhání keše [cache miss] - což je při práci se žádanými zámky běžná věc - v podstatě nulová. Správci x86 si zjevně mysleli, že výhody odstranění nehezkého přetahování o spinlocky za to stojí; nezdá se pravděpodobné, že by někdo jiný nesouhlasil.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
27.3.2008 00:13
Jardík | skóre: 40
| blog: jarda_bloguje
že by se mi někdo hodil pro vlastní debugování
27.3.2008 07:03
Pavel Vymetálek | skóre: 15
| Náchod
V tomhle stylu by muselo být "na straně klientu" (programu, hradu) a ne "na straně klienta" (pána). Takže si to ujasněteViz pomocný vzor les
.
27.3.2008 13:56
peYko | skóre: 8
| blog: /dev/null
| Žilina
27.3.2008 14:43
David Heidelberg | skóre: 46
| blog: blog_
27.3.2008 09:48
/etc/hosts. DNS server můžete použítlibovolný, co nejjednodušší. Typy DNS serverů mi budete muset dát nějaké na výběr, nenapadá mne, podle čeho by se DNS servery mohly dělit.
Informaci o tom, že CIFS umožňuje hledat počítače jenom podle DNS máte odkud? V dokumentaci k CIFS se o Netbios jménech píše, takže předpokládám, že jsou podporována…
27.3.2008 16:20
David Heidelberg | skóre: 46
| blog: blog_
27.3.2008 23:11
alblaho | skóre: 17
| blog: alblog
tohle mě rozesmálo