Jaderné noviny – 25. 1. 2018: Datová struktura XArray

20. 2. 2018 | Redakce | Jaderné noviny | 3538×

Stav vydání jádra. Kroah-Hartman: Stav Meltdown a Spectre v jádře Linux – novinky. O diskuzi věnované zmírňování Spectre. Datová struktura XArray.

Stav vydání jádra

Současné vývojové jádro je 4.15-rc9, vydané 21. ledna. Nevyšlo oznámení vydání, ale Linus vysvětlil,, že na poslední vydání 4.15 si ještě budeme muset počkat. „Opravdu jsem chtěl vydat 4.15 dnes, ale situace se neuklidnila natolik, abych z toho měl dobrý pocit, a Davem mi řekl, že má stále nějaké nedořešené opravy v síťování. Laura Abbottová našla a opravila velmi jemnou chybu zavádění, která se do vývojového cyklu dostala teprve včera, a prostě jsem se necítil na to říct, že jsme hotovi.“

Stabilní aktualizace: 4.14.15, 4.9.78 a 4.4.113 vyšly 23. ledna.

Kroah-Hartman: Stav Meltdown a Spectre v jádře Linux – novinky

Jsou tu novinky od Grega Kroah-Hartmana ve věci přístupu jádra ke zranitelnostem Meltdown a Spectre. „Z toho je vidět, že mé jádro správně zmírňuje problém s Meltdown implementací PTI (izolace tabulek stránek) a že můj systém je stále zranitelný Spectre 1. verze, ale opravdu se snaží vyřešit variantu č. 2, ale moc mu to nejde (protože jsem své jádro nesestavil překladačem se správně podporovanou funkcí retpoline).“

diskuze na Linux Weekly News

O diskuzi věnované zmírňování Spectre

Nejspíš se už skoro všichni v médiích setkali s připomínkami Linuse Torvaldse k jednomu z patchů, který se snaží řešit druhou variantu Spectre. Méně citovaná, ale mnohem informativnější je odpověď Davida Woodhouse o tom, proč ony patche vypadají tak, jak vypadají. „Proto můj první nápad, jak byl implementován v této RFC sadě patchů, spočíval v tom držet se IBRS na Skylake a všude jinde použít retpoline. ‚Mizerné patche‘ beru, ale nebyly ‚pouze bezmyšlenkovitě rozesílány‘. Pokud chceme upustit od podpory IBRS a přijmout příslušná úskalí, učiňme to jako vědomé rozhodnutí s vědomím, jak by to vypadalo, nezahazujme to potichu, protože se chudák Davey bojí, že by na něj Linus zase mohl křičet.“

diskuze na Linux Weekly News

Datová struktura XArray

The XArray data structure. Jonathan Corbet. 24. ledna 2018

Občas se ukáže, že se datová struktura nehodí pro zamýšlené využití. V ostatních případech ale problém může být i jinde – například v API, které se používá pro přístup ke struktuře. Matthew Wilcox ve své přednášce v rámci jaderné minikonference na linux.conf.au 2018 demonstroval, že to je právě případ v jádře považované datové struktury radixový strom. Přišel proto s novým přístupem ke staré datové struktuře, říká tomu „XArray“.

Jaderný radixový strom je skvělá datová struktura, řekl, ale používá se mnohem méně, než by se dalo čekat. Různé jaderné subsystémy místo ní implementují své vlastní datové struktury, které řeší stejné problémy. Zkusil to napravit tak, že několik subsystémů převedl na používání radixových stromů, přičemž zjistil, že to je náročnější, než by mělo. Problém spočívá v tom, že API radixových stromů je mizerné, uzavřel Wilcox, nehodí se na skutečné případy užití v jádře.

Součástí problému je, že terminologie kolem „stromů“ je v tomto kontextu matoucí. Radixový strom se tolik nepodobá normálním stromům, na které můžete narazit v literatuře věnované datovým strukturám. Například klasické přidání (insertion) do stromu dost dobře nevystihuje, co se skutečně děje v tomto případě. Radixové stromy také podporují koncepty jako „výjimečné záznamy“ (exception entries), které uživatelům kvůli názvu přijdou děsivé.

Tudíž se Wilcox rozhodl rozhraní opravit. Stávající datovou strukturu radixový strom ponechal beze změn. Říká, že s tím je problémů pomálu. Ale metafora popisující operace nad ní se změnila ze stromu na pole. Chová se v podstatě jako pole s automatickou změnou velikosti. V principu jde o pole ukazatelů indexované nezápornými celými čísly (unsigned long). Takový pohled lépe vystihuje skutečné použití struktury.

Radixový strom vyžaduje, aby se uživatelé sami starali o zamykání. XArray naopak ve výchozím stavu řeší zamykání samo, což jeho použití usnadňuje. Mechanismus načtení předem (preload), který uživatelům umožňuje předběžně alokovat paměť před zabráním zámků, byl odstraněn, protože rozhraní komplikoval, aniž by přinášel zásadní přidanou hodnotu.

Samotné API XArray bylo rozděleno na dvě části: normální a pokročilé API. To druhé dává volajícímu do rukou mnohem větší moc. Dá se použít například k explicitní správě zamykání. Toto API se bude používat na místech, která kladou zvláštní požadavky, příkladem budiž cache stránek. Normální API je kompletně postaveno nad pokročilým API, takže slouží jako ukázka toho, jak se pokročilé API dá použít.

Cache stránek byla upravena, aby používala XArray, řekl Wilcox, a již netrpí žádnými jemu známými chybami. Má v plánu „žádat“ o zařazení v začleňovacím okně 4.16.

Rychlý pohled na API XArray

V době psaní tohoto článku byla sada patchů XArray v šesté verzi ze 17. ledna. Čítá 99 patchů, a tak není pro slabší povahy, ale úvod do jejího fungování je k nahlédnutí v patchi věnovanému dokumentaci. Začíná se definicí pole:

#include <linux/xarray.h>

DEFINE_XARRAY(array_name);
/* or */
struct xarray array;
xa_init(&array);

Hodnota se do XArray uloží pomocí

void *xa_store(struct xarray *xa, unsigned long index, void *entry,
               gfp_t gfp);

Tato funkce uloží daný záznam entry na zadaný index. Pokud je nutné alokovat paměť, použijí se předané příznaky gfp. V případě úspěchu je návratovou hodnotou předchozí hodnota uložená na pozici index, byla-li nějaká. Záznam lze odebrat z pole tak, že se na danou pozici uloží NULL, nebo voláním

void *xa_erase(struct xarray *xa, unsigned long index);

Další varianty zahrnují xa_insert() (vložení, aniž by došlo k přepsání stávajícího záznamu) a xa_cmpxchg():

void *xa_cmpxchg(struct xarray *xa, unsigned long index, void *old,
                 void *entry, gfp_t gfp);

V tomto případě se záznam entry uloží na pozici index, ale jen tehdy, když stávající uložená hodnota odpovídá hodnotě old. Tak jako tak se vrátí hodnota uložená na pozici index.

Hodnota z XArray se získá pomocí xa_load():

void *xa_load(struct xarray *xa, unsigned long index);

Návratová hodnota je ta uložená na pozici index. Ve struktuře XArray je prázdný záznam shodný se záznamem, kde je uložen NULL, takže xa_load() nemá žádné zvláštní chování pro prázdné záznamy.

V každém neprázdném záznamu XArray jde nastavit až tři jednobitové značky; spravují se pomocí

void xa_set_tag(struct xarray *xa, unsigned long index, xa_tag_t tag);
void xa_clear_tag(struct xarray *xa, unsigned long index, xa_tag_t tag);
bool xa_get_tag(struct xarray *xa, unsigned long index, xa_tag_t tag);

Hodnoty tag jsou XA_TAG_0, XA_TAG_1 nebo XA_TAG_2. Volání xa_set_tag() nastaví daný tag v záznamu na pozici index a xa_clear_tag() tag naopak odstraní. xa_get_tag() vrací pravdu, je-li v záznamu na pozici index nastaven tag.

Obecně platí, že XArray je řídké, takže hledání neprázdných záznamů pomocí cyklu je docela neefektivní. Mělo by se tak používat pomocné makro

xa_for_each(xa, entry, index, max, filter) {
    /* Process "entry" */
}

Před vstupem do cyklu by měl být index nastavený na začátek rozsahu, přes který se má iterovat, zatímco max udává nejvyšší index, který se má vrátit. Hodnota filter se dá použít k uvedení bitů se značkami, podle kterých se protřídí nezajímavé záznamy. Během provádění cyklu se index nastaví tak, aby odpovídal aktuálnímu záznamu. Je možné změnit iteraci úpravou hodnoty index uvnitř cyklu. Je také povoleno měnit pole samotné.

V normálním API je mnoho dalších funkcí, které poskytují jiné způsoby přístupu k XArray. Vedle toho je tu celé pokročilé API pro zvláštní případy. Jako celek je API poměrně velké a složité, ale zdá se přívětivější než API radixových stromů. Současná sada patchů převádí řadu užití radixových stromů na XArray, ale nějaká ještě zbývají. Pokud ale vše půjde podle Wilcoxova plánu, k jejich přepisu dojde v dohledné době a API radixových stromů zamíří na smetiště dějin.

       

Komentáře

[Nikola Ciprich]

vedlo toho -> vedle toho

[Fluttershy, yay!]

Díky, opraveno.

[LinuxTARDIS]

XArray je řídké

No nevím, mě při slově řídké napadá něco jiného

Jasně, sparse memory se asi takto překládá, ale zní to zajímavě.

[WEQWERQWERQWR]

jo ridke se pouziva. ridka matice apod.

[Petr Ježek]

Že by opak "hustého"? :) No, tady se to týká výskytu...

[Petr Ježek]

Musím ocenit Linusův přístup, kéž by byl každý takový profesionál jako on. K RadixTree a jeho řešení jen tolik, že "pole" je sémanticky naprosto správná volba pro to, co není "větvením" Kořene (radix je latinsky kořen). Takže pro příště RadixField?