Jaderné noviny – 19. 8. 2009

14. 9. 2009 | Jirka Bourek | Jaderné noviny | 3286×

Aktuální verze jádra: 2.6.31-rc6. Citáty týdne: Linus Torvalds, Russell King, Andrew Morton. V krátkosti: Mapování dolní paměti; Bezpečnost nahrávání modulů; Mapování HugeTLB; spin_is_locked(); localmodconfig. Správa napájení za běhu. Nové API pro kfifo? Problém s vyřazováním.

Obsah

• Aktuální verze jádra: 2.6.31-rc6
• Citáty týdne: Linus Torvalds, Russell King, Andrew Morton
• V krátkosti
  • Mapování dolní paměti
  • Bezpečnost nahrávání modulů
  • Mapování HugeTLB
  • spin_is_locked()
  • localmodconfig
• Správa napájení za běhu
• Nové API pro kfifo?
• Problém s vyřazováním

Aktuální verze jádra: 2.6.31-rc6

Současné vývojové jádro je stále 2.6.31-rc6 vydané 14. srpna. Nic extra zajímavého zde není, nicméně osobně jsem spokojen s tím, že mám více commitů než obvykle. I když jsou všechny opravdu malé, cítím se díky nim užitečně. Vizte oznámení, ve kterém najdete zkrácený changelog a nějaké komentáře o opravě bezpečnostní slabiny způsobené NULLovým ukazatelem.

Současné stabilní jádro je 2.6.30.5 vydané (společně s 2.6.27.30) 16. srpna. Obě obsahují dlouhý seznam oprav pro mnoho významných problémů. Vezměte na vědomí, že 2.6.27.30 mělo problém s překladem; těsně poté bylo vydáno 2.6.27.31, které tento problém opravuje.

Současné prastaré jádro je 2.4.37.5 vydané 13. srpna s opravou nejnovější slabiny způsobené nullovým ukazatelem (která postihuje 2.4 i 2.6).

Citáty týdne: Linus Torvalds, Russell King, Andrew Morton

A mě už nebaví být hloupý. Díky tomuto patchi jsem místo toho chytrý a přemýšlím dopředu.

-- Linus Torvalds

Někteří lidé v této komunitě také mají pocit (řekli mi to sami soukromě), že někteří lidé od hlavní řady se aktivně snaží ARM komunitu podkopat – vzhledem k nedávným „diskuzím“ (čti flamewarům) ohledně věcí, jako je strom zařízení, záležitostí okolo HTC atd.

-- Russell King

Takže System.map je také součástí jaderného API? Ach jo.

-- Andrew Morton

V krátkosti

Mapování dolní paměti

Nedávné sadě zranitelností způsobených nullovým ukazatelem nepomohl zmatek ohledně toho, jak spolu reagují mmap_min_addr a bezpečnostní moduly. V jádře 2.6.31-rc7 bude několik změn, jejichž cílem je ozřejmit a racionalizovat tuto interakci – s těmito patchi již SELinux nebude obcházet kontrolu mmap_min_addr; pokud bude proces chtít mapovat paměť pod touto adresou, bude potřebovat kvalifikaci CAP_SYS_RAWIO. SELinux nicméně bude implementovat svůj vlastní paměťový limit, který bude nastaven odděleně politikou. Výsledkem je, že bude možné vypnout ochranu mmap_min_addr, ale stále umožnit mapování dolní paměti jenom některým programům.

Bezpečnost nahrávání modulů

Další změna spojená s SELinuxem – která ještě v hlavní řadě není – přidává háček [hook] do request_module(). Účelem je omezit programům v uživatelském prostoru možnost nahrávat libovolné moduly do běžícího jádra. V budoucích verzí politiky SELinuxu bude pravděpodobně možnost vyvolat nahrání modulu omezena na mnohem menší počet rolí.

Mapování HugeTLB

Vlastnost „hugetlb“ umožňuje procesům vytvořit mapování pseudoanonymní paměti na stránky, které jsou větší (možná mnohem větší), než je normální velikost stránky v systému. Pro některé druhy aplikací mohou tato mapování zvýšit výkonnost tím, že se sníží tlak na TLB [translation lookaside buffer] procesoru. Jaderný kód v takových mapováních sídlí ze stejného důvodu. Používání hugetlb stránek v uživatelském prostoru je nicméně poněkud krkolomné; vyžaduje připojit zvláštní souborový systém hugetlbfs a mapovat soubory z něj.

Eric Munson sestavil patch, který implementuje jednodušší cestu. S tímto patchem systémové volání mmap() rozpozná příznak MAP_HUGETLB; když je přítomen, jádro se pokusí vytvořit mapování do velkých stránek. Pod tím vším je mapování stále implementováno jako soubor v hugetlbfs, ale uživatelský prostor již o tom nemusí vědět.

spin_is_locked()

Jaderný kód může testovat současný stav spinlocku voláním spin_is_locked(). Co by ale tato funkce měla vracet na jednoprocesorovém systému, kde spinlocky neexistují? Kumar Gala se dostal do problémů, protože jedna implementace spin_is_locked() na jednoprocesorovém systému vrátila nulu. Problémem byl kód v této podobě:

/* Ensure we have the requisite lock */
BUG_ON(!spin_is_locked(&some_lock));

Kumar si proto myslí, že by návratová hodnota vždy měla být pravda. Jsou ale jiné situace, kdy to je špatně; Linus ukázal příklad, kde kód čeká na uvolnění zámku.

Skutečný problém spočívá v tom, že výrok spin_is_locked() prostě nemá jasně definovaný význam v situaci, kdy spinlocky neexistují. Není tedy způsob, jak v takových situacích vždy poskytnout „správnou“ odpověď. Místo toho se může stát, že v budoucích jádrech bude spin_is_locked() prohlášeno za zastaralé a místo něj se pro testování stavu spinlocku objeví nová primitiva expect_spin_locked() a expect_spin_unlocked(). Když kód dá jasně najevo, jakou odpověď očekává, bude mít výchozí hodnota smysl; obě funkce by na jednoprocesorových systémech vracely true.

localmodconfig

Mnoho testerů jádra chce přeložit jádro, které vypadá jako jádro dodané jejich distribucí. Distribuční jádra jsou nicméně dodávána v konfiguraci, která překládá téměř všechno. Náš ubohý tester tedy musí dlouho čekat, než systém přeloží spoustu modulů, které se nikdy nepoužijí. Tomu by se dalo vyhnout vytvořením konfigurace od začátku, ale to může být podobně náročné – v současném jádře je spousta konfiguračních voleb.

Steven Rostedt zaslal změnu překladového systému, která s tímto problémem má pomoci. Uživatel, který zadá

make localmodconfig

dostane konfiguraci, která přeloží všechny moduly v současnosti nahrané v běžícím systému, ale žádné jiné. To by měla být konfigurace, která podporuje hardware systému, ale postrádá stovky zbytečných modulů. Je zde také volba localyesconfig, která vloží potřebné ovladače přímo do jádra.

Správa napájení za běhu

I když byla na správě napájení linuxových systémů v nedávných letech odvedena spousta práce, většina jí byla zaměřena na správnou funkci uspání a probouzení. Správa napájení je ale víc než to; stojí za to minimalizovat spotřebu energie běžícího systému, což platí jak pro velká datová centra, tak pro laptopy; snížená spotřeba energie a menší požadavky na klimatizaci mají přínosy jak ekonomické, tak pro životní prostředí. Problém s uspáváním je nyní v podstatě vyřešen, takže se čím dál tím více pozornosti dostává dalším aspektům správy napájení; některé nedávné patche ukazují, jak se správa napájení za běhu dává dohromady.

Jádrem budoucí struktury správy napájení téměř určitě bude patch pro správu napájení za běhu Rafaela Wysockiho. Tento patch přidává do kódu správy napájení strukturu, která umožňuje uspávání a probouzení zařízení za běhu. Struktura dev_pm_ops je doplněna třemi novými funkcemi:

int (*runtime_suspend)(struct device *dev);
int (*runtime_resume)(struct device *dev);
int (*runtime_idle)(struct device *dev);

Tyto funkce mají být implementovány vnitřním kódem zařízení pro každý druh sběrnice; mohou být změněny na zpětná volání [callback] pro ovladač specifický pro sběrnici. Kód správy napájení zavolá runtime_suspend(), aby se specifické zařízení připravilo na stav nízké spotřeby. Toto volání zařízení nenařizuje, aby se uspalo, ale aby se připravilo na situaci, kdy již nebude schopné komunikovat s CPU či pamětí. Jinými slovy, i když se nebude uspávat zařízení, hardware mezi ním a zbytkem systému se uspat může. Návratová hodnota -EBUSY nebo -EAGAIN operaci uspávání přeruší.

Volání runtime_resume() by mělo zařízení připravit na to, že bude opět spolupracovat se zbytkem systému; ovladač by měl zařízení zapnout, obnovit registry a udělat všechno ostatní, co je potřeba, aby zařízení začalo fungovat. Zpětné volání runtime_idle() je zavoláno, když si jádro myslí, že zařízení nic nedělá a mohlo by být dobrým kandidátem pro uspání. Zpětné volání by poté mělo rozhodnout, jestli lze zařízení opravdu uspat (to by mohlo zahrnovat kontrolu stavu dalších zařízení k němu připojených), a poté, pokud se vše zdá v pořádku, zahájit operaci uspání.

Kromě těchto zpětných volání je zde také sada vnitřních funkcí, které jsou navrženy k řízení uspávání a probouzení, řešení zrušení operace během nich, umožnění toho, aby vnější kód mohl měnit správu napájení, a tak dál. Více informací o tom, jak tento subsystém funguje, vizte v odpovídajícím dokumentačním souboru.

Kód popsaný výše prošel několika iteracemi revidování a zdá se být na cestě k začlenění do 2.6.32. Oproti tomu Rafaelův patch asynchronního uspávání a probouzení je o něco novější a možná mu to bude trvat déle. Tento patch chce umožnit kódu správy napájení volat zpětná volání pro uspávání a probouzení asynchronně; to by umožnilo volat je paralelně. V případě, že se neobjeví žádné páry závislostí mezi zařízeními, uspávání a probouzení paralelně by mělo zrychlit změny napájení celého systému.

V závislostech je problém; spuštění několika operací správy napájení paralelně zvyšuje riziko, že pořadí bude chybné. Aby se tomu zabránilo, přidává patch do každého zařízení objekt pro dokončení [completion]; když má být zařízení uspáno, dokončení zajistí, že je závislé zařízení uspáno předtím. Při probouzení se dokončení používají v opačném pořadí: Zařízení čekají na probuzení svých rodičovských zařízení předtím, než se probudí sama. Pokud budou informace o závislostech správné, měl by tento mechanismus zajistit, že sada vláken pro správu napájení může běžet paralelně bez narušení běhu systému.

Zajištění toho, aby byly závislosti správné, bylo před lety jedním z důvodů pro vytvoření modelu zařízení v Linuxu. Se správně sestaveným stromem systém například ví, že nemůže uspat USB řadič předtím, než jsou uspána všechna zařízení do něj připojená. PCI řadič, ke kterému je tento USB řadič připojen, zase musí zůstat funkční, dokud se neuspí řadič USB, atd. Problém je, že závislosti v systému nemusí být takto jednoduché. PCI zařízení může také například vyžadovat služby I2C řadiče, popřípadě mohou být zařízení na multifunkčních čipech zkombinována překvapujícími způsoby. Ukázalo se tedy, že strom zařízení není schopen reprezentovat všechny závislosti správy napájení v systému.

Rafael tento problém řešil v pozdější verzi patche, která přidává nový framework pro reprezentaci závislostí správy napájení. Jeho jádrem je tato struktura:

struct pm_link {
    struct device *master;
    struct list_head master_hook;
    struct device *slave;
    struct list_head slave_hook;
    };

Pro každou známou závislost v systému existuje jedna tato struktura; ta říká, že každé „řídící“ [master] zařízení musí být funkční, pokud je funkční „podřízené“ [slave] zařízení. Řídící zařízení musí být uspáno po podřízeném a probuzeno před ním. Mnoho těchto spojení může vytvořit samo jádro správy napájení; ostatní budou muset generovat relevantní zařízení. Ohledně spotřeby paměti touto strukturou se objevily nějaké obavy, ale lepší řešení navrženo nebylo.

Matthew Garret mezitím posunul kód vnitřní správy napájení ještě o krok dál svojí vlastní sadou patchů pro správu napájení za běhu. Nová volání správy napájení vytlačil do vrstev PCI a USB sběrnice a použil je k oportunistickému uspávání zařízení za běhu systému; výsledkem je úspora 0,2 wattu. Komentáře od revidovatelů způsobily, že tyto patche byly staženy kvůli opravám, ale ukazují směr, kam věci míří. S dostatečnou podporou softwaru a spolupracujícím hardwarem by měl být Linux schopen dále snížit množství energie potřebné pro celé třídy systémů. A to bude určitě dobře.

Nové API pro kfifo?

Nová implementace jaderného FIFO, kfifo, není příliš využívána a Stefani Seibold by ráda, aby se to změnilo. Za tímto účelem navrhla nové API kfifo, které zapracovává mnoho z návrhových vzorů pro datové struktury popsaných Neilem Brownem. Nové rozhraní je v několika ohledech zjednodušené, takže je snazší ho používat, což by mohlo vést k většímu využití v jádře.

Základní problémy současného rozhraní kfifo pochází z omezení, která jsou kladena na jeho uživatele. Je vyžadován spinlock, i když ho většina uživatelů kfifo nepotřebuje. Strukturu kfifo také lze alokovat pouze dynamicky, takže uživatelé nemohou vložit FIFO do jiných struktur – jenom ukazatele na ně. Krom toho je podle Stefani současné API příliš jednoduché a neposkytuje mnoho důležitých vlastností.

Zatímco současné API má 9 funkcí, nové jich má 23, nicméně tento počet je dán i tím, že některé funkce mají více variant. Tyto varianty zahrnují kopírování z nebo do uživatelského prostoru, podporu záznamů o pevné délce a také možnost použít spinlocky k synchronizaci přidávání nebo odstraňování dat z FIFO. Podporuje mnoho různých případů využití ve stylu Neilova vzoru „širokých rozhraní“.

kfifo je deklarována použitím makra DECLARE_KFIFO(), které lze využít uvnitř deklarace struktury nebo sjednocení [union]. FIFO deklarované pomocí DECLARE_KFIFO() musí být inicializováno pomocí INIT_KFIFO(). Mimo deklarace struktur/sjednocení alternativně DEFINE_KFIFO() řeší jak deklaraci, tak inicializaci FIFO. Makro má parametry name (jméno proměnné nebo prvku struktury/sjednocení) a size (velikost v bytech):

DECLARE_KFIFO(name, size)
INIT_KFIFO(name)

DEFINE_KFIFO(name, size)

Dále jsou k dispozici dvě funkce podporující dynamickou alokaci bufferu:

int kfifo_alloc(struct kfifo *fifo, unsigned int size, gfp_t gfp_mask)

která alokuje buffer velikosti size bytů, přičemž kmalloc() se předávají příznaky gfp_mask. Nebo je možné k kfifo připojit předalokovaný buffer použitím:

void kfifo_init(struct kfifo *fifo, unsigned char *buffer, unsigned int size)

Buffer alokovaný pomocí kfifo_alloc() by měl být později uvolněn voláním kfifo_free().

Do bufferu se data vkládají funkcí kfifo_in():

unsigned int kfifo_in(struct kfifo *fifo, 
    unsigned char *from, unsigned int n)

Vrací počet uložených bytů. Jak bylo zmíněno výše, existují varianty pro získávání dat z uživatelského prostoru, stejně jako pro zamykání:

unsigned int kfifo_from_user(struct kfifo *fifo, 
    const void __user *from, unsigned int n)

unsigned int kfifo_in_locked(struct kfifo *fifo,
    const unsigned char *from, unsigned int n, spinlock_t *lock)

Lze uhodnout, že volání pro vybírání dat z FIFO vypadají podobně – i když obráceně:

unsigned int kfifo_out(struct kfifo *fifo, 
    unsigned char *to, unsigned int n)

unsigned int kfifo_to_user(struct kfifo *fifo, 
    void __user *to, unsigned int n)

unsigned int kfifo_out_locked(struct kfifo *fifo,
    unsigned char *to, unsigned int n, spinlock_t *lock)

V běžném případě, když je pouze jeden zapisovatel a jeden čtenář, nejsou pro přidávání a vyjímání dat z FIFO zapotřebí žádné další zámky, ale v komplikovanějších případech varianty *_locked() umožňují volajícímu použít příslušný zámek.

Jsou přítomny očekávatelné testy na to, jestli je FIFO plná a prázdná (kfifo_is_full() a kfifo_is_empty()), stejně jako funkce pro zjištění velikosti FIFO a dostupného místa (kfifo_size(), kfifo_len() a kfifo_avail()). Také je možné vyřadit nějaké byty z FIFO, aniž by je bylo nutné předávat (kfifo_skip()), nebo celou FIFO vymazat voláním kfifo_reset().

Také je doplněna podpora pro záznamy o pevné délce s tím, že jedno- nebo dvoubytová informace o délce je uložena s každým záznamem. Každé volání musí předat parametr recsize, který udává velikost pole udávajícího délku (tj. 1 nebo 2, i když 0 je povolená hodnota značící žádnou délku):

unsigned int kfifo_in_rec(struct kfifo *fifo,
    void *from, unsigned int n, unsigned int recsize)

unsigned int kfifo_from_user_rec(struct kfifo *fifo,
    const void __user *from, unsigned int n, unsigned int recsize

unsigned int kfifo_out_rec(struct kfifo *fifo,
    void *to, unsigned int n, unsigned int recsize,
    unsigned int *total)

unsigned int kfifo_to_user_rec(struct kfifo *fifo,
    void __user *to, unsigned int n, unsigned int recsize,
    unsigned int *total)

Tyto funkce vrací počet bytů, které nebyly zkopírovány, což je trochu podivné. Co se funkcí pro vyjímání dat z FIFO týče, do *total se ukládá počet skutečně kopírovaných bytů. Tato část rozhraní se zdá být poněkud podivná a možná nepřežije ve své současné podobě, nicméně zatím nebyla nijak komentována.

Celkově bylo rozhraní přijato vcelku dobře. K dřívější verzi rozhraní byly nějaké komentáře, které Stefani z větší části řešila. Jediné komentáře ohledně nejnovější verze (v0.4) byl spor mezi Alanem Coxem a Andrewem Mortonem ohledně konvencí pojmenovávání.

Alan by byl radši, kdyby současná volání kfifo_put() a kfifo_get() nebyla ještě odstraněna s poznámkou, že se právě chystáme pustit fifo ze řetězu všude v USB a v některých dalších znakových/sériových ovladačích, z nichž všechny využívají spinlocky. Současná volání používají spinlocky, takže změna, kterou Stefani navrhuje, by se musela odrazit v kódu USB a znakových/sériových ovladačů. Andrew si ale myslí, že nyní je ten správný čas pro změnu, protože kfifo nemá vůbec předpokládat, že volající chce použít zamykání spin_lock().

Základní problém je, že Andrew by rád, aby se konvence držela věcí jako že kfifo_put() (nebo kfifo_in(), jak to definuje Stefaniino API) nepředpokládá nic o zamykání. Souhlasí s jejím rozhodnutím přidat oddělené varianty kfifo_*_locked(). Alan poukazuje na to, že tato konvence není dodržována příliš konzistentně, ale Andrew je neoblomný:

Plus, jak jsem řekl asi milionkrát a všichni to stále ignorují: současné pojmenování je špatně. Obecně by kfifo_get() nemělo předpokládat, že volající chce zamykání založené na spinlocích.

Alan nejprve dal části patche NAK, ale nakonec povolil, takže tato konkrétní překážka je pryč. Zdá se, že pro 2.6.31 takováto změna přichází příliš pozdě, nicméně pokud se neobjeví nějaké významné záležitosti, je docela možné, že se nové API kfifo objeví v 2.6.32.

Problém s vyřazováním

Tradičně úložná zařízení spravují bloky dat, které jsou jim předány, bez toho, aby se zabývaly tím, jak systém tyto bloky používá. Čím dál tím více je nicméně užitečné úložným zařízením tyto informace poskytnout; konkrétně může být výhodné sdělit zařízení, že specifický blok již neobsahuje data, která jsou pro hostitelský systém zajímavá. Koncept „vyřazování“ [discard] byl do jádra přidán před rokem a měl tuto informaci zařízení předávat. O rok později se zdá, že původní nápad nepřežije setkání se skutečným hardwarem – obzvláště s úložnými zařízeními bez rotujících částí.

Funkce vyřazování má mnoho případů použití. Velká úložná pole „podnikové třídy“ [enterprise-class] mohou implementovat virtuální zařízení s mnohem větší úložnou kapacitou, než je skutečně nainstalováno; tato pole mohou využít informace o nepotřebných blocích a fyzické úložiště znovu použít pro jiná data. Mechanismus pro komprimované swapování do paměti compcache potřebuje vědět, že specifické sloty ve swapu nejsou zapotřebí, aby mohl uvolnit paměť, kterou spotřebovávají. Největší tlak na koncept vyřazování nicméně pochází od úložných zařízení bez rotujících částí (SSD) – tato zařízení implementují své algoritmy vyrovnávání opotřebení tím, že přesouvají data na flash úložišti. Bez funkce podobné vyřazování SSD stěhuje data, o která hostitelský systém nemá zájem; sdělit takovému zařízení, že se bloky nepoužívají, by mělo zvýšit jejich výkonnost.

Smutná pravda nicméně je, že vyšší výkonnost se u SSD nekoná. To má dva důvody:

• Na úrovni protokolu ATA je vyřazovací požadavek implementován příkazem „TRIM“ zaslaným zařízení. Z důvodů, které autorovi článku nejsou známy, komise pro protokol navrhla TRIM jako příkaz, který nelze řadit do fronty. To znamená, že před vysláním příkazu TRIM musí bloková vrstva nejprve počkat, než se všechny probíhající I/O operace v zařízení dokončí. Každá operace TRIM tedy zdržuje frontu požadavků. A i kdyby TRIM bylo zcela zadarmo, nemožnost řadit ho do fronty by znamenala významný dopad na výkonnost I/O. (Stojí za to poznamenat, že SCSI ekvivalent příkazu TRIM je značkový příkaz [tagged command], který tento problém nemá.)

• Se současnými SSD se TRIM zdá být jakýkoliv, jenom ne zadarmo. Mark Lord naměřil pravidelná zpoždění ve stovkách milisekund. Zpoždění takového rozsahu by na rotujících úložných zařízeních bylo velice nevítané. Na SSD je latence ve stovkách milisekund jednoduše netolerovatelná.

Dalo by se předpokládat, že druhý problém nakonec zmizí, až bude firmware v SSD zařízeních chytřejší. První problém lze ale opravit pouze změnou specifikace protokolu, takže jakákoliv možná oprava přijde nejdříve za několik let. Musíme ho považovat za fakt, se kterým je potřeba žít.

Je několik návrhů, jak by bylo možné žít s výkonnostními problémy spojenými s operacemi vyřazování. Matthew Wilcox má plán reimplementovat celý koncept vyřazování s použitím cache v blokové vrstvě. Místo zasílání požadavků přímo do zařízení si je bloková vrstva zapamatuje ve své vlastní cache. Všechny další zápisy se potom porovnají s vyřazovací cache; kdykoliv nějaká operace přepíše sektor označený k vyřazení, bloková vrstva bude vědět, že vyřazení již není třeba a může samo o sobě být vyřazeno. To omezí počet operací TRIM, které je potřeba poslat zařízení. Kdyby ale jádro mohlo pracovat na shlukování na blokovém zařízení, výkonnost by se měla ještě zvýšit. Jedním relativně snadno implementovatelným příkladem by mohlo být aktivní znovuvyužívání nedávno uvolněných slotů ve swapu místo rozhazování odswapovaných stránek po celém swapovacím zařízení. Jak to říká Matthew: Existuje lepší způsob, jak disku říct, že na obsahu bloku již nezáleží – zapsat do něj nová data.

V jeho schématu by bloková vrstva příležitostně vyprázdnila vyřazovací cache a aktuální operace vyslala na zařízení. Cachování by mělo umožnit nahromadění mnoha operací, což by výkonnost mělo ještě zlepšit. Greg Freemyer místo toho navrhuje, aby vypisování vyřazovací cache zajišťoval proces v uživatelském prostoru. Greg říká:

Předpokládejme, že budeme mít perzistentní bitovou mapu a na pozadí bude běžet prohledávač, když disk/CPU nebudou nic dělat. Ten bude jenom nepřetržitě bitovou mapu prohledávat a hledat spojité bloky nepoužívaných sektorů. Když nějaký najde, vyšle blokové vrstvě a nakonec i zařízení největší možné odmapování.

Když se objeví normální aktivita CPU/disku, proces se uspí.

Variantu tohoto přístupu zaslal Christoph Hellwig, který implementoval podporu pro dávkové vyřazování v XFS. Christophův patch přidává nové ioctl(), které prochází mapu volného místa souborového systému a pro každý volný rozsah vyšle velkou vyřazovací operaci. Výhodou přístupu na úrovni souborového systému je, že souborový systém ví, které bloky nejsou zajímavé; není potřeba žádné další shromažďování informací. Tento přístup také přirozeně generuje velké operace; větší vyřazování mají tendence lépe vyhovět požadavkům hardwaru. Na druhou stranu pravidelné vyřazování veškerého volného místa v souborovém systému má velkou pravděpodobnost, že se nějaký čas stráví tím, že se zařízení bude říkat, aby vyřadilo sektory, o kterých již ví, že jsou volné.

Je příliš brzy na to sázet se o tom, který z těchto přístupů – pokud vůbec nějaký z nich – bude začleněn do hlavní řady. Stále je potřeba odvést spoustu práce na programování a benchmarkování. Je ale jasné, že kód, který je v současné době v hlavní řadě, není připraven na to vytěžit z přicházejícího hardwaru maximální výkonnost.

Autor tohoto článku má pocit, že je potřeba upozornit na jeden možná přehlížený aspekt problému. SSD není jenom tupé úložiště; ve skutečnosti je to rozumně výkonný počítač sám o sobě, běží na něm složitý software a připojuje se přes něco, co je v podstatě vysokorychlostní síť mezi dvěma body. Některá zařízení více orientovaná na podnikové prostředí jsou takto organizována explicitněji; jsou to oddělená zařízení, která se připojují do místní IP sítě. V poslední době jejich hodnota není v čím dál tím běžnější hromadě flashových úložišť, která najdeme uvnitř; je v chytrém firmwaru, který zajišťuje, že se zařízení chová jako tradiční disk a, doufejme, má slušný výkon. Konkurence v této oblasti přinesla do tohoto firmwaru nějaká zlepšení, ale moderní SSD bychom i tak měli vidět jako to, co opravdu je: Počítač, na kterém běží proprietární software a který vkládáme dovnitř svého systému.

Tak to být nemusí; Linux nepotřebuje s flashovým úložištěm hovořit skrz hezkou překladovou vrstvu. Máme vlastní kód pro překladovou vrstvu (UBI) a pár souborových systémů, které umí pracovat s čistým flash. Bylo by velmi zajímavé vidět, co by se stalo, kdyby některý výrobce vytvořil konkurenceschopné čistě flashové zařízení dostupné jako samostatnou komponentu. Jádro by se poté mohlo zhostit úlohy správy flash a vývojáři by svou pozornost mohli obrátit k řešení problémů správným způsobem, místo toho aby obcházeli problémy v řešeních ostatních výrobců. Jaderní programátoři se již dříve explicitně rozhodli, že se vyhnou přesunu větší částí síťového stacku do hardwaru zařízení; bylo by hezké mít podobnou možnost týkající se nízkoúrovňové správy úložiště.

Když tuto možnost nemáme, nezbývá nám než se potýkat s překladovými vrstvami nabízenými výrobci hardwaru. Výsledky pravděpodobně v blízké budoucnosti nebudou optimální, ale i tak by měly být lepší než to, co máme teď.

       

Komentáře

[MX]

Russell King kdyz tak ...

[Ladicek]

Díky tomuto patchi jsem místo toho chytrý a přemýšlím dopředu.

Já ho žeru:

Now I just need a patch to make me athletic and handsome.

[Filip Jirsák]

Variantu tohoto přístupu byla zaslal Christoph Hellwig

„Byla“ je tam pravděpodobně navíc.

[Ruža Becelin]

Nazyvat jadro 2.4 "prastarym" mi prijde trochu divne :D

[Jendа]

Proč ho ještě používat? Zatím jsem slyšel jenom o jednom problému s nějakou WiFi s OpenWRT při použití 2.6.

[Limoto]

Problémem s wifinama od Broadcomu - výrobce dodává proprietární blob pro 2.4, jemuž se ovladač ve 2.6 nemůže rovnat...

[vlastikroot]

A ten hybridni port nebo kdesi cosi ? To docela funguje ne ?

[Limoto]

Ale ne jako AP, natož na MIPSu...

[petr_p]

Taková situace ovšem vůbec nastat nemůže kvůli licenci jádra, ne? :D

[snehuliak]

Suhlasim - jadro 2.4 vobec nie je prastare. Prastare bolo 2.2 ale to ako sa uz zda "zomrelo" kedze uz nie je ani na kernel.org.  Inak kernel.org - pozerali ste ake zmeny sa tam udiali?

- pribudol linux next  a

- mame tam hned 5 stablinych 2.6 jadier a jedno stabilne 2.4...

Teraz sa aspon nikto nemoze stazovat na nestabilny linux...

Hadam sa o tejto zmene docitame v buducich vydaniach Jadernych Novin ;)

[KofolaMaster]

ten Linusov komentar isiel pekne aj dalej :)

And I'm tired of being stupid. So this patch makes me smart and forward-thinking instead.

Now I just need a patch to make me athletic and handsome.