Jaderné noviny – 25. 4. 2013: Revoluce v podobě non-volatilních paměťových zařízení

13. 5. 2013 | Luboš Doležel | Jaderné noviny | 4547×

Aktuální verze jádra: 3.9-rc8. Citáty týdne: Steven Rostedt. Nebezpečí malých masek a velkých typů. Příprava Linuxu na non-volatilní paměťová zařízení: Začneme plazení; Obavy.

Obsah

• Aktuální verze jádra: 3.9-rc8
• Citáty týdne: Steven Rostedt
• Nebezpečí malých masek a velkých typů
• Příprava Linuxu na non-volatilní paměťová zařízení
  • Začneme plazením
  • Obavy

Aktuální verze jádra: 3.9-rc8

Aktuální vývojová verze jádra je 3.9-rc8 vydaná 21. dubna. Ano, skutečně jsem doufal (a měl jsem to v plánu), že během tohoto víkendu vydám konečnou verzi 3.9, ale našlo se tolik problémů, že jsem se na to necítil. Bylo to dost na hraně a žádný z problémů nebyl až tak velký a možná jsem to mohl zkrátka označit za verzi 3.9 a otevřít začleňovací okno, ale další týden nás přece nezabije.

Stabilní aktualizace: verze 3.6.11.2 vyšla 19. dubna a verze 3.5.7.11 vyšla 22. dubna.

Aktualizace 3.8.9, 3.4.42 a 3.0.75 se aktuálně revidují; jejich vydání lze očekávat 25. dubna nebo později.

Citáty týdne: Steven Rostedt

Poučka pro tento den:

yes "" | make menuconfig

je špatný nápad.

-- Steven Rostedt

Nebezpečí malých masek a velkých typů

Linus si nedávno hrál s nástrojem sparse pro statickou analýzu kódu, když narazil na zajímavý a snad i překvapivý zdroj chyb v jaderném kódu. Pravdou je, že to není žádné překvapení, jakmile pochopíte podstatu, ale i tak to představuje riziko pro netušící.

Představte si takovýto kód:

u32 bitmask = 0xff;
u64 value;

value &= ~bitmask;

Člověk by očekával, že tento kód vynuluje spodních 8 bitů ve value a to se i stane. Jenže operátor bitové negace ~ je aplikován na 32bitový typ, takže ~bitmask se vyhodnotí jako 0xffffff00 – z pohledu 64 bitů je pak horních 32 bitů nulových. Takže logická operace AND vynuluje i těchto vrchních 32 bitů, což není kýženým výsledkem.

Když se nad tím člověk zamyslí, tak toto chování dává smysl, ale i tak to vypadá jako pravděpodobný zdroj chyb v jádře. Při analýze kódu v jádře se hned našly podobné chyby v kódu pro MIPS (právě kvůli nim se tím začal Linus zabývat), v perf a v systému souborů ext4. Je možné, že se najdou i jinde. Linus dále rozšiřuje sparse, aby označoval potenciální problémy, ale i tak je vhodné, aby si vývojáři dávali na tento typ chyb pozor.

Příprava Linuxu na non-volatilní paměťová zařízení

Od úpadku centrálních pamětí se u technologií datových úložišť drží dva odlišné typy úložišť: paměť je buď rychlá a krátkodobá nebo pomalá a persistentní (trvalá). Tato situace se ale mění a to pro Linux představuje zajímavé výzvy. Jak se přizpůsobíme změnám, kde jsou non-volatilní paměťová (NVM) zařízení běžná? Ric Wheeler na toto téma měl přednášku na Linux Foundation Collaboration Summitu 2013.

Ric řekl, že o NVM se mluví už pár let. Zařízení typu NVM mají několik charakteristik, které je odlišují od jiných technologií. Jsou adresovatelné po bajtech jako běžná RAM, na rozdíl od úložných zařízení, kde to bylo vždy po blocích. Jsou persistentní: jejich stav se neztratí při odpojení napájení. Svou rychlostí, ale i cenou jsou srovnatelná s obyčejnými paměťmi, takže v blízké době nebudou tak velké jako pevné disky. Zatím si s nimi většina z nás nemůže za rozumnou cenu hrát.

První SSD vypadaly hodně jako disky; používaly obvyklé protokoly a nebyly tak rychlé, že by je systém nestíhal používat. Tato situace se ale spolu s další vlnou zařízení, která jsou obvykle připojená přes PCIe, změnila. V I/O vrstvě sídlí mezi systémem a úložištěm spousta kódu; s rostoucí rychlostí úložišť představuje jeho režie čím dál větší problém. Většina tohoto kódu není v této situaci moc k užitku, protože ten byl navržen pro zařízení s vysokou latencí. Následkem toho není na Linuxu stále možné z SSD připojených přímo k řadiči získat maximální výkon.

Ric měl nakolik návrhů, jak vyladit současné linuxové systémy pro práci se stávajícími rychlými blokovými zařízeními. Relevantní parametry najdeme pod /sys/block/dev/queue, kde dev je název příslušného blokového zařízení (například sda). Parametr rotational je nejdůležitější; pro SSD by měl být nastaven na nulu. I/O plánovač CFQ (vybraný atributem scheduler) není pro SSD tím nejlepším; deadline je lepší volba. Je také nutné dávat pozor na velikost bloků daného zařízení a podle toho zarovnat systémy souborů; více o tom v tomto PDF.

Zpět k tématu – Ric poznamenal, že kromě technických problémů jsou tu i organizační komplikace. Jaderní vývojáři jsou obvykle dost specializovaní: SCSI a SATA disky řeší rozdílní lidé. Samotnou blokovou vrstvu má na starosti oddělená, malá skupina. Za každým systémem souborů stojí zase jiný tým a těch máme opravdu mnoho. A všechny tyto skupiny lidí musejí spolupracovat, aby zařízení NVM na Linuxu fungovala optimálně.

Začneme plazením

Pro plné využití NVM budou nutné nové programovací modely a API. Na takovou změnu je třeba čas, ale hardware tu může být cobydup. Proto Ric říká, že je musíme se současnými API rozchodit co nejlépe, co to jen půjde; tomu říká „plazení“. V této fázi budou zařízení NVM používána přes původní blokové API, stejně jako SSD teď. Klíčem bude tato API co nejvíce urychlit. Je to prý škoda, ale potřebujeme blokový ovladač, který z těcho cool věcí udělá cosi nudného. Z kódu pro I/O je také nutné vypudit nadbytečnou režii.

Ted Ts'o navrhoval, že ačkoliv je obtížné přesunout aplikace k novým API, je snadné zařídit, aby je knihovny jako sqlite používaly. To by mohlo aplikacím přinést výkonnostní zlepšení beze změn v kódu. Bylo poukázáno na to, že uživatelé jsou někdy líní aplikace třeba jen překompilovat, takže než se to dostane ke koncovým uživatelům, může to chvíli trvat.

Současný stav „plazení“ je takový, že blokové ovladače pro NVM jsou ve vývoji. Jsme také svědky cachovacích technologií, které umí využívat NVM pro rychlejší přístup k tradičním úložným zařízením. Do verze 3.9 byl začleněn target dm-cache a mechanismus bcache jde do verze 3.10. Ric řekl, že ve vývoji jsou i různá řešení specifická pro konkrétní výrobce.

Přechod do fáze „chůze“ znamená upravit stávající systémy souborů. Jedním evidentním vylepšením může být přesun žurnálů na rychlejší zařízení; lze přesunout i často vyžadovaná metadata. Pro získání nejvyššího výkonu bude ale nutné předělat transakční logiku, tedy zbavit se existujících bariér a operací flush. Btrfs má aktuálně částečnou schopnost „dynamic steering“, která je krokem v tomto směru, ale přesto zbývá spousta práce.

Je také na čase uvažovat o vytvoření nových API pro aplikace pro přístup na úrovni bajtů; vývojáři aktuálně uvažují nad tím, jak by vývojáři mohli chtít k NVM přistupovat. Ric zmínil, že ctihodné rozhraní mmap() bude muset podstoupit důkladné zhodnocení a „nemusí být možné ho zachránit“. Vývojáři aplikací se budou muset o schopnostech zařízení NVM naučit a k tomu je nejprve nutné jim do rukou dát příslušný hardware.

To nemusí být snadné. Během přednášky si mnoho lidí stěžovalo, že tato zařízení jsou „skoro k mání“ už posledních deset let, ale přesto se nikdy neobjevila. Tejun Heo řekl, že nic není vytesané do kamene; nikdo neví, jakou výkonnostní charakteristiku budou zařízení mít a jak by se pro ně mělo optimalizovat. Říká se, že to by se mělo změnit a vývojáři by měli dostat hardware jako první (pod NDA). Ale zatím je těžké něco odhadovat.

Pak Ric řekl, že ve fázi „běhu“ budou nová API na úrovni zařízení, která budou moci systémy souborů a úložiště používat. Budeme mít nové systémy souborů navržené přímo pro NVM (později se mluvilo o tom, že Fusion-IO takový systém souborů má a v budoucnu jej uvolní). Storage Network Industry Association má pracovní skupinu věnovanou právě těmto problémům. Ric řekl, že přechod chvíli potrvá a bude bolestivý, podobně jako přechod na 64bitové systémy.

Obavy

Následná diskuze se dotkla řady témat, prvním byla jednoduchá otázka: proč nepoužívat zařízení NVM jako RAM, ze které zkrátka po vypnutí nezmizí obsah? Problémem tohoto přístupu je to, že ačkoliv se NVM může chovat jako RAM, jiné aspekty – jako životnost – se mohou lišit. Přílišné zápisy na zařízení NVM mohou jeho životnost značně zkrátit.

Dále se mluvilo o tom, jak bude obecně těžké podporu těchto nových typů zařízení do Linuxu dostat. Komunita je víc než jen jádro; pro vytvoření úplného systému je nutné více vrstev projektů. Pro mnoho výrobců je tato komunita záhadou. Dotáhnout funkce do stavu, kdy jsou uživatelům užitečné, může trvat mnoho let. Příkladem je paralelní NFS, na kterém se pracuje alespoň deset let, ale teprve teď se mu dostává komerční podpory – a to jen na klientech.

Dalším bodem diskuze byla replikace dat. S obyčejnými blokovými zařízeními je replikace dat mezi více zařízeními relativně jednoduchá. Se zařízeními NVM, ke kterým přistupuje uživatelský prostor přímo, mizí bod, kde je možné komunikaci odchytávat, takže jádro nemá jak data replikovat.

Došlo i na téma důvěryhodnosti zařízení. Aplikace nemusejí být zvyklé na to řešit paměťové chyby; to se možná bude muset změnit. Nová API budou proto muset obsahovat funkce pro počítání kontrolních součtů a kontrolu chyb. Boaz Harrosh poukázal na to, že dokud nebudeme znát chybovou charakteristiku těchto zařízení, nebudeme se proti chybám moci bránit.

Abychom to shrnuli: blížíme se do nového zajímavého světa, ale zatím není stále jasné, jak ten svět bude vypadat a kdy k nám vlastně dorazí. V době, kdy zařízení NVM budou běžně dostupná, pro ně snad už budeme v jádře mít dobrou podporu, ale komplikovanějšímu softwaru možná potrvá, než bude schopen nového hardwaru plně využít. Bude to zajímavý přechod.

       

Komentáře

[lertimir]

Super. Konečně se něco se SSD děje. Pár let už píšu, že SSD je v podstatě paměť a jako s pamětí by se s ní mělo zacházet. Konečně to vypadá, že tenhle názor budou mít i jaderní vývojáři.

[ertwertwe]

jeste to bude chtit priblizit tyhle pameti blize CPU. ma vubec ssd neco jako execute in place jako NAND, NOR pameti??!

[R]

NAND nepodporuje execute-in-place a pristup k nej ma blizsie k disku ako k RAM.

[j]

Ono to neni o SSD - s SSD bohuzel jako s pameti zachazet nemuzes, protoze nelze primo adresovat - mas v ceste radic. Pave proto, aby se to chovalo "jako disk". Navic i kdyby tam ten radic nebyl, nemuzes adresovat min nez jednu bunku, coz neni jeden byte, ale prevazne 64kB.

Ale blizka budoucnost by mela vest k tomu, ze se vyhodej dram moduly nebo pujde do stejnych slotu napichat prave tyhle "nemizejici" pameti.

Ad reseni - me teda zminovany pristup jako RAM prijde logickej a jedinej rozumnej. Zajistit, aby se na to moc nezapisovalo ... prece neni az takovej problem - pokud to kernel spravne rozpozna (coz by jit melo) tak proste bude vedet, ze na adresach od-do sidli prave takovahle pamet, a ze se k ni ma podle toho chovat. Pak do ty casti umisti sebe, moduly ... a dalsi nezbytnosti, jako trebas casto spousteny aplikace, pricemz do casti s dramkou muze umistovat data.

Vymejslet jak z toho udelat neco na cem bude filesystem mi prijde postaveny na hlavu.

[ertwertwe]

ruzne rpi, beagle boardy jsou fyzicky tomu blize nez pc s ssd. procesor primo s nand/nor pametemi.

[lertimir]

No to je jasné, že SSD má řadič. Myslel jsem samozřejmě přímo adresovatelné zařízení, založené na NAND nebo NOR flash chipech. A to s tou RAM jistě není tak jednoduché. Kernel jistě rozpozná kde je RAM a kde NVR, ale mnohem hůře rozpozná, co dát do RAM a co do NVR. V podstatě totiž s NVR vzniká zcela principielně nové paměťové medium (čtvrté) (nové z hlediska fyzikálních zákonů a způsobů práce s ním) a je z dlouhodobého pohledu třeba vymyslet, zpracovat a prosadit, jak s ním pracovat. Ty tři existující média myslím:

1. přímou adresací bytů - RAM
2. blokové zařízení s přímým přístupem - disk
3. proudové zařízení - pásková jednotka

s každým typem média se pracuje jinak. Flash je blízké RAM právě jen v operaci čtení a naopak v operaci zápisu má blízkost k blokovým zařízením.

Osobně si myslím, že dlouhodobě nejlepší a nejčistčí by bylo zavést jinou alokaci paměti pro paměť v NVM něco jako nvmalloc() a postupně přepisovat kód tak, aby části, které se jen čtou, mohly být v NVR, protože jen autor kódu ví, co bude potřebovat zapsat jen jednou. Ale nevěřím, že se to stane, byl by to příliš velký zásah do systému i aplikací.

Mnohem více věřím, že bude vznikat nový filesystém, který nebude figurovat jako blokové médium, ale jako médium nového typu a nebude mít ty vrstvy, které optimalizují použití blokových zařízení s velkou latencí a navíc bude mít zcela jinou strukturu, protože mazací blok, zapisovací blok a čtecí adresa/blok mají zcela jiné velikosti a na ně je třeba práci optimalizovat. (tak jako pro práci s diskem je jiná optimalizace než pro práci s páskovou jednotkou)

[Sten]

Mezi 1 a 2 patří ještě EEPROM, kde zápis je blokový a čtení přímou adresací bajtů. Stejně se chová i SSD.

Takových souborových systémů existuje několik (JFFS2, YAFFS, YAFFS2, UBIFS, LogFS) a používají je například všechny telefony s Androidem.

[Sten]

Tohle nemá s SSD nic společného, týká se to MRAM, FeRAM a podobných technologií

[lertimir]

flash memory je stejně tak nonvolatile jako MRAM a FeRAM.

Flash memory is an electronic non-volatile computer storage device that can be electrically erased and reprogrammed.

(První řádek z Wikipedie.) To jestli se jiné technologie uchytí či dokonce zvítězí bude záležet na tom, kolik nabídnou vlastností za ekonomicky přijatelnou cenu. V současnosti se u NVM jedná v prvé řadě o flash. Jasně, že SSD má navíc řadič, který, i vzhledem k tomu, že se dosud nedohodli, co by vlastně za charakteristiky flash memory měla sdělovat OS, fixluje a předstírá systému, že je to disk. Ale tohle je fakticky to, co jsem psal už před tím časem: Flash musí poslat reálné údaje o své charakteristice a v systému se musí vyrobit nový přístup/zařízení k tomuto novému druhu paměti.

[R]

Lenze k MRAM a FeRAM sa pristupuje ako k RAM. Tak sa pristupuje aj k NOR flash pri citani. Ale velkokapacitne flash su vzdy NAND a tam je pristup uplne iny.

[Sten]

Pevný disk a páska jsou taky non-volatilní paměti

SSD nedokáže provádět opakovaný zápis na náhodnou pozici, což je základní vlastnost (a vůbec definice) všech RAM pamětí. SSD je akorát velká EEPROMka, není potřeba vymýšlet nové způsoby přístupů pro něco, co existuje a používá se už desítky let. On-chip flash paměti (například ty vestavěné v telefonech s Androidem) se ani jako disky netváří a systém s nimi tak zachází (u Androidu pomocí YAFFS2).