Jaderné noviny - 14. 3. 2007

5. 4. 2007 | Robert Krátký | Jaderné noviny | 4125×

Aktuální verze jádra: 2.6.21-rc3. Citáty týdne: Rusty Russell, Linus Torvalds. Jaderné události bez kevents. paravirt_ops je považováno za škodlivé? RSDL narazil.

Obsah

• Aktuální verze jádra: 2.6.21-rc3
• Citáty týdne: Rusty Russell, Linus Torvalds
• Jaderné události bez kevents
• paravirt_ops je považováno za škodlivé?
• RSDL narazil

Aktuální verze jádra: 2.6.21-rc3

Aktuální předverze řady 2.6 zůstává 2.6.21-rc3 (ke 14. 3. 2007). Od vydání -rc3 si do hlavního repozitáře našlo cestu přibližně 250 patchů; -rc4 by měla vyjít co nevidět.

Aktuální verze -mm jsou dvě. Liší se pouze tím, že jedna obsahuje RSDL (2.6.21-rc3-mm1) a druhá ne (2.6.21-rc3-mm2).

Stabilní jádro 2.6 je 2.6.20.3 a bylo vydáno 13. března s pár desítkami oprav. 2.6.20.2 vyšlo 9. března s celou stovkou patchů.

Starší jádra: 2.6.16.43 bylo vydané 8. března a od té doby už vyšlo i 2.6.16.44-rc1 s několika opravami, včetně dvou bezpečnostních patchů.

Citáty týdne: Rusty Russell, Linus Torvalds

-#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0])		      \
+	+ sizeof(typeof(int[1 - 2*!!__builtin_types_compatible_p(typeof(arr), \
+		 typeof(&arr[0]))]))*0)

-- Rusty Russell

Rusty, tohle je umělecké dílo.

Ale navrhuji, abys to raději už nikdy nikomu neukazoval. Jsem si jistý, že za padesát let to bude mít mnohem větší cenu. Takže to drž pěkně pod pokličkou, aby si lidi nevyškrábali oči^W^W^W^W^W^W^W aby nevydělali hromady peněz na trhu s uměním.

-- Linus Torvalds

Jaderné události bez kevents

Dlouhý příběh subsystému kevent už jsme probírali mnohokrát. Kevents jsou navrženy tak, aby měly aplikace k dispozici jediné systémové volání, které mohou použít pro čekání na jakoukoliv událost, co je zrovna zajímá: I/O, časovače, signály a další. Ačkoliv se na kódu hodně pracovalo, cestu do jádra má dlouhou. Dost vývojářů ještě není přesvědčeno, že je takové rozhraní potřeba. A pokud ano, jestli je navrhované API kevent (které by muselo být navždy spravované) to pravé. Teď se objevil konkurenční přístup, který by možná komunita spíše přijala.

Davide Libenzi je autorem systémového volání epoll_wait(); je to verze poll(), která by měla být škálovatelná na velké počty popisovačů [descriptors]. Jde o API, které je dobré v tom, co dělá, ale čekání na popisovače souborů ho omezuje. Mnohé věci, které kevents řeší, není spojeno se soubory, takže s nimi rozhraní epoll nic nezmůže.

Kevents tento nedostatek napravuje vytvořením nového subsystému a uživatelského API. Davide přišel s jinou strategií: umožnit aplikacím žádat doručení událostí prostřednictvím popisovače souboru. Vezměme jako příklad signály. Signály se aplikacím často obtížně zpracovávají; jsou to asynchronní události, které jsou doručovány speciální funkci pro zpracování signálů - ale tato funkce má velmi omezené možnosti. Vývojáři aplikací na to reagovali používáním triků; například zapíší bajt do interní roury, takže může být signál zpracován v hlavní smyčce událostí.

Davide navrhl nové systémové volání nazvané signalfd(), které by vývojářům aplikací mohlo pomoci většinu potíží při práci se signály přeskočit:

    int signalfd(int ufd, const sigset_t *mask, size_t masksize);

Je-li ufd -1, pak toto volání vytvoří (a vrátí) nový popisovač souboru. Signály popsané v mask budou zachyceny a přes popisovač souboru vráceny procesu. Signály mohou být zpracovávány ve smyčce událostí založené na select(), poll() nebo epoll_wait(). Když jsou signály k dispozici, mohou být z popisovače čteny jako data; struktura signalfd_siginfo, kterou vrací read(), obsahuje číslo signálu a všechny informace, které jsou s ním spojeny.

Je-li ufd nastavena na existující signální popisovač souboru, změní se volání signalfd() na novou mask. Stojí za zmínku, že čtení z tohoto popisovače souboru soupeří s běžným doručením signálu z fronty signálů; nedá se předpovědět, jestli bude signál doručen běžným způsobem, nebo přečten z popisovače souborů. Této situaci lze předejít použitím sigprocmask() k zablokování běžného doručování.

Pro události časovače je podobné rozhraní:

    int timerfd(int ufd, int clockid, int timertype, 
                const struct timespec *when);

ufd je opět buď -1 (vytvoří se nový popisovač souboru), nebo existující časovačový popisovač souboru, který má být upraven. Parametr clockid popisuje, které hodiny chceme: CLOCK_MONOTONIC nebo CLOCK_REALTIME. Typ časovače je určen pomocí timertype: TFD_TIMER_REL pro čas odvozený od aktuálního času, TFD_TIMER_ABS pro absolutní čas nebo TFD_TIMER_SEQ pro časovač opakující se ve stanoveném intervalu. Struktura when obsahuje požadovanou dobu.

I z tohoto popisovače souboru lze číst. Dostanete celočíselnou hodnotu, která značí, kolikrát časovač spustil od posledního čtení.

Jevgenij Poljakov, autor kevent patchů, mezitím vytvořil eventfs; jde o speciální souborový systém, který nabízí možnost vázat události na popisovače souborů. První verze patche umí pracovat pouze se signály (prostřednictvím systémového volání - opravdu - signalfd()):

    int signalfd(int signal, int flags);

Toto volání vytváří nový popisovač souboru pro daný signal (tato implementace vyžaduje samostatný popisovač souboru pro každý signál). Je-li hodnota flags nenulová, bude signál doručen pouze přes eventfs a vůbec se nedostane do fronty signálů. Popisovače souboru se lze dotazovat [pollable], ale neexistuje způsob, jak z něj číst nějaké informace. Takže informace spojené se signálem jsou ztraceny; stejně tak jsou ztracena několikanásobná doručení stejného signálu mezi jednotlivými dotazy.

Dá se předpokládat, že Evgeniovy patche by mohly být časem vylepšeny, ale Davideova verze se zdá být co do funkcí, záběru a kontroly ze strany komunity dále. Davide se také vyhnul vytváření nového souborového systému. Takže pokud by se přijímaly sázky na to, čí patche se dostanou do jádra, Davide by teď vedl.

Takový přístup má určitě něco do sebe. Přibližuje Linux jednotnému rozhraní pro doručování zpráv, aniž by potřeboval nové a komplexní API. Také posiluje roli popisovače souboru coby základního objektu pro interakce s jádrem. Na druhou stranu, rozhraní poll nenabízejí aplikacím žádný způsob, jak přijímat události bez volání jádra - vlastnost, kterou někteří vyžadovali. Také existují druhy událostí, které zatím nejsou podporovány (například dokončení asynchronního I/O). Takže pokud bude vybrán tento způsob, začnou se asi brzy objevovat patche, které by měly tyto mezery zaplnit.

paravirt_ops je považováno za škodlivé?

Ve srovnání s jinými flame wary byl tento o něco více technický a neprůhledný. Základní problém: je přidání vrstvy paravirt_ops, která se teď začíná používat pro podporu spouštění Linuxu pod hypervizory, dobrá věc nebo katastrofa (z hlediska dlouhodobé správy)?

Všechno začalo přidáním nového patche do -mm; vypadá to, že některé věci v novém kódu clockevents způsobily, že virtualizační vrstva VMI nefunguje. Vývojáři VMware tedy připravili opravu, která ale se nelíbila vývojářům clockevents. Podle nich brala oprava příliš mnoho staršího kódu, kterého se tak usilovně zbavovali, a dávala ho zpátky do jádra ve vrstvě VMI. Thomas Gleixner takovým řešením nadšen nebyl:

Tohle je dost nechutné. NO_HZ povoluje funkce dynamického ticku [dyntick] v idle(), irq_enter() a irq_exit(), takže kód clockevents je ve skutečnosti volán. Nedíval jsem se tak podrobně, abych zjistil, proč to vůbec funguje. Mám takový pocit, že "dobře funguje" znamená něco jako "nevybuchne".

Správným řešením by podle Thomase bylo, kdyby všichni lidé, kteří pracují na hypervizorech v Linuxu, přišli s jediným rozhraním časovače založeným na clockevents. To by, podle jeho názoru, nemělo být tak těžké. Programátoři VMI jsou možná ochotni něco takového časem udělat, ale nepovažují to za věc, která by mohla být hotova brzy. Jejich aktuální kód funguje a navíc mají těsně před vydáním nového produktu, takže se jim nechce do věcí příliš šťourat.

"Těsně před vydáním nového produktu" ale není omluva, která by to v LKML měla snadné. To platí dvojnásob, když si někteří z dotčených lidí myslí, že vývojáři VMI měli s příchodem clockevents počítat a během minulého roku se na to rozhraní měli připravit. Aktuální VMI časovačový kód vidí z hlediska údržby jako začátek dlouhé noční můry.

Ingo Molnar diskuzi rozšířil i na obecné problémy, které podle něj paravirt_ops přinášejí. Je to dlouhý email, ale hlavní myšlenkou se zdá být toto: z každého připojení hypervizoru implementovaného pomocí paravirt_ops se stane ABI, které musí být v jádře udržováno navěky. Samotné rozhraní paravirt_ops by mělo jádro oddělovat od změn - a toto API se měnit může. Ale každé hypervizorové rozhraní vytvořené pomocí paravirt_ops musí fungovat i v budoucnu, takže nebude možné provádět některé zásadní změny. Udržování kompatibility s několika hypervizory bude těžké a Ingo čeká nepříjemnosti, až jednou dojde k nevyhnutelné chybě:

Nezáleží na tom, jestli si myslíme, že to pohnojil VMWare. Uživatelé/zákazníci budou dávat vinu nám: "v2.6.25 nefunguje, nechce běžet pod ESX v1.12". Distro povolí a odstraní změny, které narušují zpětnou kompatibilitu se staršími hypervizory (nejspíš už to bude vráceno i u autora změn). Zpětná kompatibilita představuje velmi silnou zábranu proti určitým druhům změn v designu paravirt_ops.

Moc dalších lidí však tento názor nepodpořilo. Aktuální nepěknosti jsou vnímány jako věci, které půjdou opravit, na budoucí údržbu se lidé dívají optimisticky a především asi většina úplně ignoruje debaty o virtualizaci. Linus navrhl, aby Ingo ukázal na konkrétní problémy (a případně je opravil, pokud ho trápí) místo všeobecného stěžování. Ingo reagoval v tom smyslu, že hypervizorová rozhraní by měla být brána jako nová systémová volání a přidávána stejně opatrně a s rozmyslem.

Nakonec nebylo jasné, jestli k nějaké změně dojde. O přidání podpory hypervizorů do jádra je velký zájem a je nepravděpodobné, že by se ten proces teď zastavil. Do budoucna lze tedy očekávat ještě váznější strkanice týkajících se hypervizorových rozhraní. Budeme-li mít štěstí, bude to sice hlučný proces, ale vyústí v evoluci paravirt_ops kódu, který bude snadné dlouhodobě spravovat.

RSDL narazil

Když se objevil Rotating Staircase Deadline Scheduler (RSDL), ohromoval testery nalevo i napravo. Jeden člověk jej chtěl dokonce zařadit rovnou do jádra 2.6.21. Ve skutečnosti však náhrada tak důležité věci, jako je plánovač procesoru, nemohla být tak jednoduchá. Takže není překvapivé, že RSDL narazil na pár překážek.

Největší potíž je asi tato zátěž, kterou reportoval Mike Galbraith. Mike se pokoušel nechávat na pozadí běžet různé žrouty procesoru (hlavně enkódování MP3), zatímco sledoval nějaké interaktivní eye candy. Je to zátež, která se současným plánovačem funguje, ale s RSDL je odezva pomalá. Objevilo se i několik dalších reportů o viditelném zpomalení interaktivní práce, když na pozadí probíhají velké počty - i když zase jiní reportovali lepší výsledky.

Není nic nečekaného na tom, že se u určitých zátěží objevily horší výkony. Málokdo by očekával, že bude RSDL dokonalý hned první týden po vydání. A tak je hlavní potíž v tom, že Con Kolivas, tvůrce RSDL, reagoval trochu podrážděně, a odmítl takové chování považovat za regresi:

Tvoje představy o tom, co by mělo být možné dělat, jsou prostě mimo. Zjisti si, jak vypadala rovnováha u starého plánovače (a myslím, že to nebylo o moc více procesoru pro X), a prostě u svého lame encoderu změň nice - stejně už to nastavuješ.

Nemůžeme už pokračovat v hádkách o tom, jestli se zbavit neférovosti, nebo se nám to později vrátí. Máme dobré interaktivní reakce s férovým plánovačem, ale přitom to vypadá, že tobě jde jen o to, abys ho přehltil a našel v něm chyby.

Con zastává názor, že plánovač by se měl snažit poskytovat férové služby a nízkou latenci; jakékoliv další požadavky na interaktivní reakce by měly být řešeny vyladěním úrovní nice. S "odhadovačem" interaktivity, který je zabudován do stávajícího plánovače, se pracuje špatně; jádro by nemělo mít tyhle věci na starosti. Problém je, že takový přístup neodpovídá tomu, na co jsou uživatelé zvyklí.

Jakmile začneme pro tyto situace řešit zlepšení interaktivity u RSDL, bude z toho stará známá debata o zlepšení interaktivních reakcí obecně. Linus podotkl, že způsob, jakým RSDL provádí plánování, není tak férový, jak by mohl být:

Problém je, že spousta klientů nakonec dělá *více* v X serveru. Například zobrazení řádky textu na obrazovce je daleko náročnější než jen udržování přehledu o takovém řádku, takže si pak plánovač snadno pomyslí, že X server má "příliš moc" procesorového času a ostatním klientům se nedostává. A výsledkem je špatné interaktivní chování.

Řešit se to dá dvěma způsoby preferování X serveru: buď tak, že se nějak označí jako základ celé interaktivní práce, nebo prostým zvýšením priority. Con upřednostňoval druhý způsob; proto také poslal samostatný patch, který je určen pro zlepšení latencí všech procesů, i když všechny neběží se stejnou prioritou.

Tyto potíže by nemusely zabránit zařazení RSDL do hlavního jádra. Výhody spojené s odstraněním heuristik odhadujících interaktivitu jsou velké a vypadá to, že mnoha uživatelům RSDL dobře funguje. Znatelné zhoršení výkonnosti v některých případech je však problém; nikdo nechce čelit hromadě mailů od nespokojených uživatelů ("s 2.6.x mám reakci na houby"). Takže se dá očekávat pár dalších verzí a možná ještě jedna nebo dvě verze jádra, než to bude moci být začleněno.

       

Komentáře

[clayman]

Ten kód v citátu je zralý na umístění do The Daily WTF...

[ApoC]

To bude spis Aprilovy diff ;)

[Messa]

Může mi prosím někdo vysvětlit, co má ten kód dělat? (To původní počítalo počet prvků v poli, to je mi jasné, tedy doufám.) Co tam dělají ty vykřičníky?

[marek_s]

myslim, ze to *0 na konci by Ti to mohlo vysvetlit

[danfis]

Ty vykricniky jsou negace negace a jsou tam na stejne veci jako to okolo - umelecky dojem ;)

[Sinuhet]

Vraci pocte prvku v typu pole. A pokud mu predate parametr typu ukazatel na neco, tak skonci chybou pri prekladu.

[Sinuhet]

Tady to dokonce rozebiraji.

[egg]

Aha, takže není pravda, že dělá jen dojem. Naopak tam každý znak dává smysl. Má to totiž vedlejší efekt, že překladač vyhodí varování, pokud typ parametru není pole.

[Kyosuke]

Nedělá a je to vysoce funkční, jen to "!!" je tam potenciálně navíc, nebo mi to aspoň přijde. Zdůvodňovat vykřičníky myšlenkovým exprimentem "It's easy to envisage a situation..." mi přijde směšné, neb je to stejně nestandardní fíčura a tam, kde funguje (GCC) je definovná jednoznačně, žádnou hypotetickou situaci neberu. (Hmm, nebo mi něco ušlo?)

[egg]

Na druhou stranu proč to tam nenapsat, když to může ušetřit hypotetické problémy. Beztak to makro vygeneruje jen konstantu v době překladu, takže ve výsledném kódu se to nijak neprojeví. A když už člověk místo čitelnosti vytváří umělecké dílo...

Připomíná mi to jednu matematickou funkci... Kdo pozná, co to dělá?

f(x) = \lim_{n\to\infty} \sgn\sin^2(n! \pi x)

[michich]

Rozhoduje, jestli x je/neni racionalni?

[egg]

Přesně. Líbí se mi, že žádný symbol tam není zbytečný. Dirichletova funkce je 1-f(x). Ve wiki je napsaná sice bez signum, ale zato přes dvě limity.

[Filip Jirsák]

V části RSDL narazil: zatěž, kterou reportoval Mike Galbraith s/zatěž/zátěž/

[Robert Krátký]

Dík, opraveno.

[petr_p]

Linusova reakce na Rustyho je spatne prelozena: jedno ^W uberte :D

[Milan Vít]

Možná se pletu, ale spíš bych odebral rovnou dvě

[Boris Dušek]

Je to zátež, která se současným procesorem funguje,

nemá tam být spíš "se současným plánovačem"?

[Robert Krátký]

Má . Díky, opravil jsem.