AbcLinuxu:/ Články / Jaderné noviny – 7. 4. 2010

Štítky: boot, jádro, ladění, monitorování, sítě, sledování, TCP, virtualizace, výkon

Jaderné noviny – 7. 4. 2010

30. 4. 2010 | Jirka Bourek | Jaderné noviny | 2938×

Aktuální verze jádra: 2.6.34-rc3. Citáty týdne:. Režim perfu „naživo“. Patche NO_BOOTMEM. Správa paměti pro virtualizaci. Směrování toku přijímaných dat. Mechanismus pro paralelní zpracování padata.

Obsah

Aktuální verze jádra: 2.6.34-rc3
Citáty týdne:
Režim perfu „naživo“
Patche NO_BOOTMEM
Správa paměti pro virtualizaci
Směrování toku přijímaných dat
Mechanismus pro paralelní zpracování padata

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

link

Současné vývojové jádro je stále 2.6.34-rc3, ale -rc4 lze očekávat každou chvíli. Od -rc3 se do jádra dostalo poměrně hodně patchů; většina jsou opravy, ale také zde máme pročištění 4200 souborů od Tejuna Heo a nový ovladač pro ethernetové adaptéry založené na Chelsio T4.

Stabilní aktualizace: Greg Kroah-Hartman oznámil vydání čtyř různých verzí stabilních jader: 2.6.27.46, 2.6.31.13, 2.6.32.11 a 2.6.33.2. Jsou to poměrně velké aktualizace, které mají 45, 89, 116 a 156 patchů v daném pořadí (při revizi, některé patche mohou být zahozeny). Jako obvykle je uživatelům důrazně doporučeno aktualizovat. Krom toho se zdá, že stabilní aktualizace 2.6.31 se blíží svému konci, takže uživatelé těchto jader by měli přejít na .32 nebo .33.

Citáty týdne:

link

4208 files changed, 3717 insertions(+), 717 deletions(-)

-- Tejun Heo rozhodil do -rc4 velkou síť

Mám dva stroje, které vykazují velmi rozdílná čísla, co se výkonnosti týče. Po trošce zkoumání jsem zjistil, že první stroj má v /proc/cpuinfo

model name : Intel(R) Celeron(R) M processor 1.00GHz

kdežto ten druhý:

model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz

a zdá se, že to je hlavní rozdíl. Problém je v tom, že /proc/cpuinfo je pouze pro čtení. Bylo by možné umožnit zápis do /proc/cpuinfo tak, abych na prvním stroji mohl udělat:

echo -n "model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz" > /proc/cpuinfo

a získat tak výkon podobný druhému stroji?

-- Paulo Marques

Pravděpodobně je to pekelně zabugované, ve skutečnosti nemám odvahu nabootovat to svinstvo, které píšu.

-- Linus Torvalds

Režim perfu „naživo“

link

napsal Jake Edge, 7. dubna 2010

Sledovací nástroj perf se vyvíjí rychle. Když jsme se dívali naposledy, Tom Zanussi přidal do perfu skriptování v pythonu a perlu. Další krok je podle všeho režim naživo, ve kterém perf již nepotřebuje dělení na dva kroky – záznam dat a analýzu. Režim naživo umožňuje, aby perf trace record a perf trace report komunikovaly pomocí roury, přičemž výsledky je možné okamžitě a nepřetržitě zobrazovat na výstupu (a la top).

Aby současní uživatelé nemuseli měnit své skripty, přidal Tom nové vlastnosti, se kterými perf pozná, že výstup operace record směřuje na stdout a vstupem operace report je stdin. V takovém případě perf data přenáší rourou a používá speciální syntetizované události, ve kterých poskytuje hlavičky. To také perfu umožňuje fungovat přes síť tak, že se jeho výstup rourou přesměruje do netcatu a na jiném systému se netcatem přečte a rourou nasměruje do report.

Všechny skripty, které jsou nainstalovány do standardního umístění perfu (tj. ty, které jsou vypisovány pomocí perf trace -l) mohou automaticky běžet v režimu naživo:

$ perf trace syscall-counts

spustí oba konce skriptu syscall-counts s rourou mezi nimi, což je použitelnější zkratka pro:

$ perf trace record syscall-counts -o – | perf trace report syscall-counts -i -

což je samo o sobě zkratka pro:

perf record -c 1 -f -a -M -R -e raw_syscalls:sys_enter -o – | \
perf trace -i – -s ~/libexec/perf-core/scripts/python/syscall-counts.py

Tom také zahrnul několik příkladových skriptů ve stylu topu, které lze používat pro monitorování aktivit čtení/zápisu a systémových volání a které jsou aktualizovány v intervalu tří vteřin. To vše se zdá být velmi užitečný přírůstek perfu, ze kterého se rychle stává švýcarský armádní nůž pro monitorování jádra.

Patche NO_BOOTMEM

link

napsal Jonathan Corbet, 7. dubna 2010

Zdá se, že každý vývojový cyklus jádra obsahuje jednu sadu patchů, která bude problematičtější, než se očekávalo. U 2.6.34 by toto ocenění pravděpodobně mělo připadnout patchům, které lze nalézt pod trochu matoucím názvem CONFIG_NO_BOOTMEM.

„Bootmem“ je jednoduchý, nízkoúrovňový alokátor používaný jádrem během počátečních fází bootu. Jeden by si mohl myslet, že jádro žádný další alokátor nepotřebuje, ale kód pro správu paměti pro svou práci vyžaduje, aby byla velká část jádra funkční. Aby bylo možné dostat se do takového stavu, je zapotřebí řetěz postupně se komplikujících mechanismů alokace paměti; ty na architektuře x86 začínají mechanismem „early_res“, který přebírá štafetu po mechanismu „e820“ BIOSu. Jakmile se věci dostanou trochu dále, přichází na řadu bootmem alokátor specifický pro architekturu, který je nakonec nahrazen hlavním alokátorem.

Yinghai Lu dospěl k názoru, že věci by bylo možné značně zjednodušit, kdyby z tohoto obrazu zmizela fáze s bootmem. Výsledkem je série patchů, která rozšiřuje mechanismus early_res natolik, aby bylo možné s jeho pomocí nastartovat hlavní alokátor. Tyto změny byly začleněny do 2.6.34, ale starý kód alokátoru založeného na bootmem zůstal na místě. Volba CONFIG_NO_BOOTMEM určuje, který alokátor se použije, výchozí nastavení je takové, že se bootmem obejde.

To je významná změna kritického a záludného kódu počátečních fází bootu, takže jenom pár lidí překvapilo, když byly proti 2.6.31-rc1 hlášeny regrese. Když ale hlášení přicházela i po -rc3, narostla nespokojenost natolik, že Linus začal mluvit o tom, že celou tu věc odstraní [revert]. Nezdálo se, že by někomu vadil cíl daných patchů, ale regrese zabíjející systém i po -rc3 společně s chaotickými #ifdefy vytvořenými patchem a fakt, že novinka byla ve výchozím nastavení zapnutá, vedly k nespokojenosti.

Normálně se od nových vlastností očekává, že budou ve výchozím nastavení vypnuty; nové jádro by se mělo v co největším možném rozsahu chovat jako jeho předchůdce, když se použijí výchozí nastavení. V tomto případě výchozí nastavení vedlo k významným změnám a problémům. Tato volba měla dva účely: Umožnit odstranění kódu konfigurací, pokud se ukáže, že bude problematický, a zajistit, že bude dobře otestován. Obojí mělo úspěch, i když se ukázalo, že někteří testeři netestovali úplně dobrovolně.

V době psaní tohoto článku se zdá, že nejhorší problémy byly opraveny; řeči o odstranění kódu vyřazujícího bootmem ustaly. Nakonec možná podobné změny provedou všechny architektury a kód bootmem bude možné odstranit úplně. Yinghai mezitím chystá pro 2.6.35 další sadu patchů; ty nahrazují kód early_res alokátorem „logický blok paměti“ [logical memory block], který používají některé jiné architektury. Tato změna vypadá ještě rušivěji, než bylo odstranění bootmem.

Správa paměti pro virtualizaci

link

napsal Jonathan Corbet, 7. dubna 2010

Autor článku již nějaký čas tvrdí, že na úrovni jádra je virtualizace víceméně vyřešena. Většina práce zbývá v oblasti výkonnosti, přičemž zajistit, aby měl virtualizovaný systém dobrou výkonnost, není malý nebo triviální problém. Jeden z nejzajímavějších aspektů tohoto problému je průnik mezi správou paměti virtualizovaných hostů a hostitele. Několik patchů, které jsou diskutovány, ilustruje, na čem se v této oblasti pracuje.

Sada patchů pro transparentní velké stránky [transparent huge page] zde byla popsána v říjnu – tento patch se snaží změnit to, jak jsou velké stránky v linuxových aplikacích používány. Většina současných uživatelů velkých stránek musí explicitně zajistit jejich používání, přičemž správce systému k tomu musí dopředu vyhradit paměť; vizte nedávno vydaný seriál Mela Gormana, kde najdete víc informací o tom, jak to funguje. Tato povaha velkých stránek, podobná konceptu „nutno složit doma“, v mnoha situacích omezuje jejich použití.

Patch transparentních velkých stránek se místo toho snaží poskytnout velké stránky aplikacím, aniž by tyto aplikace musely mít nějaké povědomí o tom, že takové stránky existují. Když jsou velké stránky dostupné, aplikacím mohou být jejich rozházené stránky spojeny do jedné velké automaticky; velké lze také rozdělit zpět na jednotlivé, když bude potřeba. Když bude systém pracovat v tomto režimu, velké stránky lze využít v mnoha situacích, aniž by o tom aplikace nebo administrátor věděli. Ukazuje se, že tato vlastnost je obzvláště prospěšná, když běží virtualizované hostované systémy; velké stránky se dobře kryjí s tím, jak hostitelé vidí a používají svůj adresový prostor.

Patch transparentních velkých stránek si propracovává svou cestu k přijetí, i když je zde třeba poznamenat, že někteří vývojáři stále ještě mají proti této práci námitky. Andrew Morton nedávno upozornil na to, že tato sada patchů má ještě další problém:

Zdá se, že tyto patche byly zaslány pouze do linux-mm. Linus linux-mm nečte a nikdy je neviděl. Myslím, že bychom s ním měli projednat celkový záměr a přístup k implementaci, než se pokusíme pokračovat… tohle je velká sada patchů a hraje si s oblastí, kde je o Linusovi známo, že má – ehm – názory.

Linusovi netrvalo dlouho a do konverzace se zapojil přímo; po několika odbočkách, které se přímo netýkaly výhod patche transparentních velkých stránek, zjistil, že tato práce je motivována potřebami virtualizace. V tom okamžiku ztratil zájem:

Myslel jsem si, že se jedná o zajímavější zátěž, než tuhle. Nemůžu si pomoci, ale zátěž „nepřítomnost záznamů v TLB je drahá“ u virtualizace mě nezajímá. Moje odpověď je „pořiďte si lepší CPU“.

Pokračoval tím, že že přirovnal transparentní velké stránky k horní paměti, kterou následně nazval propadákem. Správné řešení je v obou případech pořídit si lepší CPU.

Zde je vhodné upozornit, že horní paměť byla obzvláště úspěšným propadákem, protože o několik prodloužila použitelnost 32bitových systémů. A stále se objevuje na místech, kde to člověka překvapí – telefon autora článku běží s jádrem, které má povolenou horní paměť. Takže říci, že horní paměť je propadák, je podobné jako říci, že floppy mechanika je propadák; teď již možná nemá velké využití, ale byly doby, kdy jsme za ni byli rádi.

Jednou možná pokroky v architektuře procesorů způsobí, že transparentní velké stránky budou také zbytečné. Jenže i když alternativa k horní paměti (64bitové procesory) byla na obzoru dlouho, není úplně jasné, jaký pokrok v procesorech by mohl způsobit, že transparentní velké stránky nebudou relevantní. Takže kdyby se tento kód dostal do jádra, možná by se mohl stát jedním z těch propadáků, které se budou mnoho let hodně používat.

S tím spojené diskutované téma byl nedávno zaslaný patch s ovladačem VMware balloon. Balón má zajímavou úlohu; jeho prací je nafouknout se v hostovaném systému, zabrat paměť a znepřístupnit ji tak procesům, které pod daným hostem běží. Stránky zabrané balónem lze poté vrátit zpět hostitelskému systému, který pro ně pravděpodobně má důležitější využití někde jinde. Vypuštění balónu paměť zase zpřístupní hostovi.

Účelem tohoto ovladače je zjevně umožnit hostiteli, aby dynamicky vyvažoval spotřebu paměti hostovanými systémy. Je to poměrně hrubý nástroj, ale je také nejlepší, který máme. Andrew Morton nicméně zpochybnil potřebu mít oddělené mechanismy pro řízení paměti. Jádro již nyní má funkci nazvanou shrink_all_memory(), kterou lze použít a vynutit si uvolnění paměti. Tato funkce se v současnosti používá pro hibernaci, ale Andrew si myslí, že by ji bylo možné adaptovat i pro použití ve virtualizaci.

Jestli je to opravdu tak, se ještě uvidí; zdá se, že hlavní část složitosti nespočívá v uvolnění paměti, ale v komunikaci mezi hostitelem a hypervizorem. Kromě toho dlouhodobé řešení bude pravděpodobně sofistikovanější než jednoduché zatlačení na hosta a následné pozorování, jak se kroutí, než se mu podaří uvolnit dostatek stránek. Jak to řekl Dan Magenheimer:

Historicky všechny operační systémy měly (relativně) pevně dané množství paměti a vzhledem k tomu, že velikost byla pevně daná, nedávalo smysl s ní plýtvat. Ve virtualizovaném světě by operační systémy měly být vycvičeny k větší flexibilitě, protože co je pro jeden virtuální stroj „plýtvání“, tam by jiný virtuální stroj mohl/měl by volat „to chci“.

Jeho odpověď na tento problém je patch přechodné paměti, který umožňuje operačnímu systému označit oblasti paměti, které je možné odebrat, ale které přitom mohou obsahovat užitečná data.

Zjevně se jedná o oblast, která potřebuje další práci. Hlavní důvod virtualizace je vzájemné oddělení hostů, ale trochu kooperativnější přístup k paměti vyžaduje, aby si tito hosté byli nějak vědomi, že se soupeří o zdroje, jako je paměť, a reagovali odpovídajícím způsobem. Jako horní paměť a transparentní obrovské stránky mohou být nakonec i balónové ovladače považovány za velký propadák. Než ale přijde něco lepšího, budeme je potřebovat.

Směrování toku přijímaných dat

link

napsal Jake Edge, 7. dubna 2010

Dnešní stále se zvětšující šířka pásma společně s rychlejším síťovým hardwarem způsobují, že jediné CPU jenom těžko stíhá. Více jader a pouzder pomohlo na vysílací straně, ale přijímání je složitější. Patche směrování přijímaných paketů [receive packet steering, RFS] Toma Herberta, na které jsme se dívali loni v listopadu, poskytují způsob, jak směrovat pakety na konkrétní CPU v závislosti na hashi dat protokolu z paketu. Tyto patche jsou aplikovány na strom subsystému síťování a míří do 2.6.35. Herbert je ale nyní zpět s vylepšením RPS a pokouší se směrovat pakety na to CPU, na kterém běží přijímající aplikace: Směrování přijímaného toku [receive flow steering, RFS].

RFS používá tabulku hashů RPS a ukládá do ní CPU, na kterém běží aplikace, když ta volá recvmsg() nebo sendmsg(). Na toto CPU se poté RFS pokouší předat data místo toho, aby se vybralo libovolné CPU podle hashe a masky zpočátku nastavené správcem. Podle hashe spočítaného při přijetí paketu se RFS snaží najít „správné“ CPU a paket přiřadit tam.

Maska CPU u RPS, kterou lze nastavit pro každé zařízení komunikující po síti (a pro každou frontu u zařízení, která mají víc front) přes sysfs, reprezentuje seznam povolených CPU, kterým lze přiřadit paket. Dynamická změna těchto hodnot sice zavádí možnost přijímání paketů mimo pořadí, ale pro RPS s většinou statickými maskami to nutně nebyl velký problém. U RFS, kde se může objevit několik vláken, která budou číst ze stejného socketu a která zároveň mohou potenciálně poskakovat mezi jednotlivými procesory, se ale pravděpodobnost paketů mimo pořadí zvyšuje.

To bylo u RFS považováno za ztracený případ, jak řekl Herbert, takže byl zapotřebí jiný přístup. Aby se pakety mimo pořadí eliminovaly, jsou vytvořeny dva typy hash tabulky, obě jsou indexovány hashem vypočítaným z informací v paketu. Do globální rps_sock_flow_table se při volání recvmsg() či sendmsg() zaznamenává číslo CPU, kde běží aplikace (je nazýváno „požadované“ CPU). Každá fronta v zařízení poté dostane rps_dev_flow_table, která obdrží informaci o tom, které CPU bylo naposledy použito ke zpracování paketů pro dané spojení (nazývá se „současné“ CPU). K tomu je v záznamu rps_dev_flow_table uložena hodnota koncového čítače nezpracované fronty současného CPU.

Tyto dvě hodnoty CPU se porovnávají, když se určuje, které CPU bude paket zpracovávat (to probíhá v get_rps_cpu()). Jestliže současné CPU (zapsané v hash tabulce rps_dev_flow_table) není nastaveno (pravděpodobně se jedná o první paket), nebo je toto CPU offline, použije se požadované CPU (z tabulky rps_sock_flow_table). Pokud jsou obě hodnoty stejné, samozřejmě se použije dané CPU. Pokud jsou obě hodnoty platná čísla CPU, ale odlišná, bere se v potaz koncový čítač fronty.

Nezpracované fronty obsahují na začátku čítač, který je inkrementován, když se z fronty odejme paket. Z něj a z délky fronty lze vypočítat hodnotu koncového čítače – tato hodnota je uložena v rps_dev_flow_table. Když se jádro rozhoduje o tom, kterému CPU má být paket přiřazen, je potřeba zvážit jak současné CPU (to, které naposledy použilo jádro), tak požadované CPU (to, které naposledy použila aplikace pro příjem nebo vysílání).

Jádro porovnává koncový čítač fronty (uložené v hash tabulce) s počátečním čítačem daného CPU. Jestliže je koncový čítač menší nebo roven počátečnímu čítači, znamená to, že všechny pakety patřící danému spojení vložené do dané fronty byly zpracovány. To znamená, že přechod k požadovanému CPU nevyústí v pakety mimo pořadí.

Herbertův současný patch funguje pro TCP, ale patche RFS by měly být použitelné pro další protokoly orientované na tok. Jejich výhoda je to, že umožňují dosáhnout lepší lokality CPU při zpracování paketu jak v jádře, tak v aplikaci samotné. V závislosti na různých faktorech – jako příklad jsou dány hierarchie cache a aplikace – může a dokáže RFS zvýšit počet paketů, které lze zpracovat za sekundu, a zároveň snížit latenci, než je paket zpracován. Zajímavé ale je, že na jednoduchých benchmarcích nemusíme vždy vidět zlepšení a občas vidíme zhoršení.

U složitějších benchmarků zvýšení výkonnosti vypadá významně. Herbert poskytl čísla pro běh netperfu, kde nejlepší počet transakcí za sekundu bez RFS i RPS byl 104k, přičemž při nejlepší konfiguraci s RPS se zvýšil na 290k a u RPS s RFS dokonce na 303k. Jiný test, kde 100 vláken zpracovávalo požadavky a odpovědi podobné RPC, přičemž se v uživatelském prostoru odváděla nějaká práce, ukazoval ještě dramatičtější výsledky: Tento test ukázal 103k, 174k a 223k, ale také snížení latence jak u RPS, tak u RPS + RFS.

Tyto patche pochází od Googlu, o kterém se ví, že už nějaký ten paket na Linuxu zpracoval. Jestliže se RFS používá na produkčních systémech u Googlu, pravděpodobně se chová dobře, co se výkonnosti a spolehlivosti týče, nejenom u benchmarků. Patche byly zaslány 2. dubna a zdánlivě byly dobře přijaty, takže je těžké říci, kdy se dostanou do hlavní řady. Ale pravděpodobné je, že je uvidíme v 2.6.35 či 36.

Mechanismus pro paralelní zpracování padata

link

napsal Jonathan Corbet, 7. dubna 2010

Jednoho dne si Andrew Morton četl linux-kernel, když narazil na patch, který opravoval malý problém v kódu „padata“. Andrew, jak se zdá, o padata, které bylo začleněno během začleňovacího okna 2.6.34, nikdy neslyšel. A tak se zeptal: OK, v zájmu tisíců se ptám: Co je k čertu kernel/padata.c? V zájmu těchto tisíců se autor článku rozhodl zjistit, co tento nový kousek vnitřního jaderného kódu dělá a jak ho použít.

Ve zkratce: Padata je mechanismus, kterým může jádro paralelně zpracovat nějakou úlohu na několika CPU, přičemž zachová pořadí úkolů. Byl vyvinut pro kód IPsec, který potřebuje provádět šifrování a dešifrování velkého množství paketů bez změny jejich pořadí. Vývojáři crypto napsali padata dostatečně obecně, takže je jej možné použít i jinak, ale to znamená vědět, že je API k dispozici a jak ho používat. Aktualizaci adresáře s dokumentací bohužel vývojáři tolik práce nevěnovali.

První krok při používání padata je nastavení struktury padata_instance, která řídí to, jak se spouští úlohy:

#include <linux/padata.h>

struct padata_instance *padata_alloc(const struct cpumask *cpumask,
                                     struct workqueue_struct *wq);

cpumask popisuje, které procesory budou zpracovávat práci předanou této instanci. Pracovní fronta wq je fronta, kde se ve skutečnosti bude zpracování odehrávat. Přirozeně by to měla být vícevláknová fronta.

Dále máme funkce pro povolení a zakázání instance:

void padata_start(struct padata_instance *pinst);
void padata_stop(struct padata_instance *pinst);

Tyto funkce doslova nedělají nic jiného, než že nastavují nebo nulují příznak „bylo voláno padata_start()“; jestliže tento příznak není nastaven, ostatní funkce odmítnou fungovat. Někdo v této funkci zjevně spatřuje nějakou hodnotu, ale jediný současný uživatel padata (crypto/pcrypt.c) ji nepoužívá. padata_start() tedy vypadá jako jedno z těch cvičení ze zbytečné byrokracie, se kterou se všichni musíme jednou za čas vyrovnat.

Seznam CPU, která se mají používat, lze upravit těmito funkcemi:

int padata_set_cpumask(struct padata_instance *pinst,
                       cpumask_var_t cpumask);
int padata_add_cpu(struct padata_instance *pinst, int cpu);
int padata_remove_cpu(struct padata_instance *pinst, int cpu);

Změna masky CPU ale vypadá jako drahá operace, takže by to pravděpodobně nemělo být děláno příliš často.

Předání práce instanci padata vyžaduje vytvoření struktury padata_priv:

struct padata_priv {
    /* Další věci… */
    void                    (*parallel)(struct padata_priv *padata);
    void                    (*serial)(struct padata_priv *padata);
};

Tato struktura téměř určitě bude zabudována do nějaké větší struktury specifické pro práci, která má být odvedena. Většina polí je privátní pro padata, ale struktura by měla být při inicializaci nulována a měly by být poskytnuty funkce parallel() a serial(). Tyto funkce budou volány procesem, který zpracovává úlohu, což uvidíme za chvíli.

Práce se zadá voláním:

int padata_do_parallel(struct padata_instance *pinst,
                       struct padata_priv *padata, int cb_cpu);

Struktury pinst a padata musí být připraveny tak, jak je popsáno výše; cb_cpu specifikuje, které CPU se použije pro závěrečné zpětné volání [callback], když je práce dokončena; musí být v CPU masce současné instance. Návratová hodnota z padata_do_parallel() je poněkud podivná; nula je chyba, která značí, že volající zapomněl na formality ohledně padata_start(). -EBUSY znamená, že někdo někde jinde něco dělá s maskou CPU instance, zatímco -EINVAL je stížnost na to, že cb_cpu není v masce CPU. Když všechno projde dobře, funkce vrátí -EINPROGRESS, což znamená, že je úloha zpracovávána.

Každá úloha předaná padata_do_parallel() je následně předána jednomu volání výše zmíněné funkce parallel() na jednom CPU, takže skutečného paralelismu se dosáhne tím, že se předá víc úkolů. Tato volání pochází z pracovní fronty, takže parallel() běží v kontextu procesu a může spát. Funkce parallel() dostává jako jediný parametr ukazatel na strukturu padata_priv; informace o skutečné práci, kterou je potřeba odvést, je pravděpodobně zjišťována pomocí container_of(), která najde nadřazenou strukturu.

Všimněte si, že parallel() nemá žádnou návratovou hodnotu; subsystém padata předpokládá, že parallel() od daného bodu přebírá za úlohu odpovědnost. Práci není nutné během tohoto volání dokončit, ale pokud parallel() nechá něco nedokončené, měla by být připravena na to, že bude zavolána znovu s novou úlohou předtím, než se předchozí dokončí. Když se úloha dokončí, parallel() (nebo kterákoliv funkce, která ve skutečnosti úlohu dokončila) by o tom měla informovat padata voláním:

void padata_do_serial(struct padata_priv *padata);

Někdy v budoucnu padata_do_serial() spustí volání funkce serial() ze struktury padata_priv. Toto volání proběhne na CPU požadovaném původním voláním padata_do_parallel(); i to se provede přes pracovní frontu, ale s lokálním zakázáním softwarových přerušení. Berte na vědomí, že toto volání může být na chvíli odloženo, protože kód padata se nejprve ujišťuje, že jsou úlohy dokončeny v tom pořadí, v jakém byly zadány.

Zbývající funkce API padata by měla být zavolána, pokud již instance padata není zapotřebí:

void padata_free(struct padata_instance *pinst);

Tato funkce bude aktivně čekat, pokud je ještě potřeba dokončit nějaké úlohy, takže nebude nejlepší ji volat, dokud zbývá nějaká práce. Pokud je potřeba, ukončení pracovní fronty je nutné provést zvlášť.

API popsané výše je to, které lze nalézt v jádře 2.6.34-rc3. Jak jsme viděli na začátku tohoto článku, o padata se lidé teprve dozvídají a někteří vývojáři ohledně API pokládají dotazy. Změny jsou tedy možné, ale to vlastně platí pro jakékoliv vnitřní jaderné rozhraní.