Intel pracuje na pětiúrovňové tabulce stránek

PowerPC taky třeba.

V posledních letech se v jádře hodně předělávalo tak, aby 4KiB stránka v RAM = cluster na disku, protože v alokačních kódech bylo neuhlídatelné množství míst, kde mohlo dojít k deadlocku. Byl by to tedy krok zpět. Pokud by se měly na x86 používat větší stránky, musel by se kód pro tuto architekturu předělat a nešlo by jen tak vzít kód z jiné architektury. Tudy, bych řekl, tedy cesta nevede.

0) když je cluster = page, není co řešit, což je výhoda
1) Když je cluster < page, pak musíte mít pomocnou datovou strukturu s evidencí. Přístupy k ní se musí zamykat (režie), konkurenční přístup hrozí deadlockem (netriviální odhalení). Jednoznačně se to nevyplatí.
2) Když je cluster > page, pak musí jádro alokovat souvislý úsek, což pro jádro není problém. Ale může s tím nastat problém, když budou volné fyzické stránky fragmentované, protože jádro to bude muset řešit. Bude potřeba dodatečná evidence dlouhých úseků, což jsou zase problémy.
3) ALE! Co když v případě 2) budu mít alokační jednotku stejnou, jakou má blok na zařízení? U klasického (moderního) HDD je (adresovatelný) blok 4KiB (dříve 512 bajtů). Jenže disk čte najednou obvykle 128 KiB (když už je hlava na místě). Pokud si řeknu, že mi o čtení jde, bude pro mne výhodné udělat si alokační jednotku takhle velkou. Ovšem vzniká vnitřní fragmentace, problém spojité alokace, mírně složitější evidence. Zvětší se vliv zarovnání (resp. případné chyby).
4) Mohu-li použít jinou velikost page, pak bych měl řešit body 1 až 3 úplně stejně s ohledem na možný tradeoff pro mé nasazení (workload). Vznikne mi však problém vnitřní fragmentace, což nemusím řešit, pokud provozuji jen vlastní aplikace (výpočetní cluster) nebo jednu aplikaci (databáze).

Jádro samozřejmě takové potíže řešit umí. Ale je otázka, zda se mi jako poučenému správci chce špinit si ruce, když nemusím. Obávám se však, že už jsme totálně mimo záběr této zprávičky.

Na druhou stranu mi není jasné, kde se tam bere ten limit na 2^52 B fyzické paměti.

Že by fyzický počet drátů koukajících ven z CPU pro adresaci? Podle mě jeden z důvodů, pro "sériové" paměti, jako je HBM, aby se pořád nemusely přidávat nožičky/plošky.

Bity, které odpovídají offsetu ve stránce, se používají na příznaky, které patří dané stránce, nejsou nevyužité (dirty bit, paged, out, nx, read only, executable atd). Aby se s tím při převodu virtuální->fyzická adresa dobře počítalo, musí být položky v tabulce stránek násobky slova (32/64 bitů). Takhle, kdyby to nebyly násobky, by se to rozjíždělo přes sousední slova a to by bylo nevýhodné (musely by se dělat před přepisem horních bitů virtuální adresy nejdřív bitové posuvy a jejich velikost by se musela počítat). Asi by se to dalo udělat přes nějaké chytré zjednodušení nebo přes hradlové pole, takže by to bylo rychlé, ale stejně by to byla komplikace a to nikdo nechce.

Co se týká shody velikosti stránky a clusteru na disku, řeší to problém skrytých a těžko odhalitelných deadlocků při alokaci, přepočtech - jak v ovladači filesystému, tak při manipulaci s buffery a cache, aktualizaci dat, zpětných zápisech na disk. Aby se to nemuselo řešit, používá se rovnost. Ale když chcete, můžete samozřejmě přepočítávat. Akorát se pak zvyšuje riziko, že se to sekne. A když chcete riziko eliminovat/zmenšit, tak se prostě některým věcem budete vyhýbat. Dodavatel (SAP, Oracle) vám třeba řekne, že podporovaná konfigurace je prostě nějaká a vy se přizpůsobíte, protože oni vědí, co dělají. Na svém písečku si samozřejmě můžete dělat co chcete, což je pointa opensource.

Ohledně počtu drátů v patici CPU, trochu bych to rozvedl:

V dobách, kdy v patici CPU byla vyvedena sběrnice FSB, tzn. uvnitř pouzdra CPU bylo skutečně pouze CPU jádro a jeho cache (nebo dvě nebo čtyři jádra), měly některé procesory skutečně 32 bitů pro celý fyzický adresní prostor. Toto odpovídá cca dobám Pentia IV (Netburst) a prvním generacím ATOMů. Do fyzického adresního prostoru se musí vejít PCI config space a mapovaná okna PCI MMIO. Poslední generace procesorů s vyvedenou FSB měly v patici 36 adresních bitů (tuším spodní 3 nebyly přítomny, protože data FSB byla široká 64 bitů = 8 bajtů). Tahle doba (FSB) skončila u Intelu procesory Core2Duo a čipsetem i4x series (včetně).

V následující generaci (první Core i3/5/7 series) se north bridge = řadič paměti přestěhoval do pouzdra CPU, a FSB zmizela někde uvnitř pouzdra (později uvnitř čipu). Potažmo procesory mají vyvedenu pouze sběrnici paměťovou - která má na daném modelu CPU určitý počet kanálů (dnes na desktopu dva, ale bývaly i tři, u Xeonů čtyři) a na každém kanálu určitý počet obsloužitelných "ranků", DIMM patic, a naadresovatelných gigabajtů. Kromě toho Intel, inspirován AMD a jeho HyperTransportem (který má původ tuším u DEC Alpha), zavedl u více-paticových strojů (Xeon e5) svou vlastní "štíhlou CPU-to-CPU sběrnici" zvanou QPI. Takže tu máme patrně dokonce tři čísla, kolik paměti daný CPU podporuje:

1) kolik gigabajtů a v jaké skladbě DIMMů umí obsloužit řadič paměti, v součtu za všechny kanály. Vstupují do toho single/dual/quad-rank DIMMy a u některých modelů také generace sběrnice, např. DDR2 vs. 3, a také přítomnost/absence ECC. Podrobnosti bývají v datasheetu konkrétního modelu (nebo rodiny) CPU.

2) jakou interní délku adresy má jádro (+ cache) při přístupu na on-chip řadič RAM a HT/QPI/PCI-e root complex. Toto je obdoba staré dobré FSB - a asi úplně nehraje roli, zda je uvnitř čipu mezi jádry CPU, kešemi a MCH blokem pořád jenom FSB nebo už něco jiného: maticový přepínač, nějaký toroidní token bus apod. Do této "šířky na rozhraní jádra CPU" se vedle RAM musí vejít taky PCI config space a MMIO okna. Tohle číslo jsem nikdy v datasheetech nehledal, možná není ani uvedeno. U jedno-paticových platforem (desktop a entry server) bohatě stačí, pokud je to číslo dvojnásobkem podporované kapacity fyzické RAM.

3) jakou délku adresy transportuje HT/QPI. Tím by teoreticky mohlo být omezeno, kolik fyzické RAM lze osadit v jediném vícepaticovém NUMA systému (Xeon E5/E7 apod.). Tohle číslo neznám.

Další věc je, jak velký NUMA systém lze postavit z dostupných CPU co mají HT/QPI = jaká další omezení ta stavebnice má (max. počet NUMA uzlů, krát max. RAM na NUMA uzel). Něco umí samotné procesory od daného výrobce, ale další expanzi lze třeba zařídit pomocí HT/QPI čipsetů třetích stran.

Pokud to správně chápu, nemá velký smysl stavět systém, který bude mít terabajty RAM pro několik málo CPU jader. Jako efektivnější mi připadá obecnější NUMA, kde k určitému počtu paměťových modulů patří vždycky hrst CPU jader (a to celé je NUMA uzel). Každopádně to nebudou malé sestavy pro velký počet zákazníků. Ani bych to neviděl na servírování virtuálů někde v cloudu. Nejspíš se bude jednat o relativně akademickou specialitku pro HPC. Pokud to má být provozně spolehlivé, mělo by to podporovat hot-swap NUMA uzlů apod. A popravdě mi přijde, že i pro velkou část HPC úloh už není velký rozdíl, jestli je stroj echtovní NUMA, nebo nějaký volnější cluster (IB/PCI-e/Ethernet v backplanu) - přičemž ten volnější cluster bude odhadem levnější a vrozeně shovívavější k výpadkům jednotlivých uzlů...

Pokud správně chápu, stránkovací tabulky jsou uložené v RAMce a prohrabuje se jimi jádro CPU. Čili není to záležitost čipsetu, nebo něčeho "jižně od FSB". Záležitostí čipsetu bývaly MTRR, ale to se jednak týká relativně omezené a obskurní oblasti IO (přístupu na periferie skrz PCI a spol.), druhak údajně roli MTRR přebrala "page attribute table", což je rozšíření/apendix stránkovacích tabulek, o kterých pojednává tento článek.

BTW PCI a PCI-e odedávna podporuje 64b adresaci, v případě paralelní PCI i na 32b fyzické šířce (dual address cycle). Tady se bavíme o adresách na PCI sběrnici, které mají relativně blízko k fyzickému adresnímu prostoru CPU. Okna sběrnicových adres se mapují skrz PCI/PCI-e root complex... kam vlastně? do virtuálního prostoru jádra? Google bus_to_virt / phys_to_virt... To vypadá, že na x86 vč. x86_64 je sběrnicový adresní prostor PCI přímo mapovaný do fyzického adresního prostoru hostitelského CPU :-)

Vážení pánové ohledně ioremap() máte samozřejmě pravdu, sám jsem tuhle funkci párkrát použil, v dobách kdy jsem ještě občas něco napsal... bus_to_virt() a phys_to_virt() zmiňuju jenom proto, že vrhají maličko světla na mapování těch adresních prostorů. Následující výstřižek pochází z arch/x86/inclu­de/asm/io.h :


/*
* However PCI ones are not necessarily 1:1 and therefore these interfaces
* are forbidden in portable PCI drivers.
*
* Allow them on x86 for legacy drivers, though.
*/
#define virt_to_bus virt_to_phys
#define bus_to_virt phys_to_virt


Takže nejsem o moc moudřejší, než jsem byl :-) Zřejmě rovnost bus=phys kdysi platila, ale dnes už nemusí nutně platit...

Stránkování je tady proto, aby se alokovaná oblast aplikaci jevila jako souvislá, přestože je fyzicky v paměti fragmentovaná. To co popisujete byl problém někdy v době DOSu ;-).

Virtuální adresní prostor je pro aplikace. Jádro potřebuje fyzicky souvislé úseky, aby se na nich dalo dělat I/O, protože I/O zařízení nemají o virtuálních adresách ani ponětí a pracují s fyzickými adresami. Offload kopírování z/do RAM přes BusMaster (dříve DMA) bohužel potřebuje souvislý úsek RAM, tj. fyzicky navazující stránky paměti... jinak by to bylo úděsně pomalé.

...což nemění nic na tom, že když chcete přenést data > page, pak bude nejlepší, když se to provede na jeden zátah a potřebujete souvislý úsek (používá se pro přístup k disku, síťové karty). Po jednotlivých 4KiB to bude komplikovanější.

Pokud máte novější systém (RHEL6, SLES 11, Debian tuším ne), jádro se snaží používat souvislé 2MiB stránky (THP, Transparent Huge Pages), problém defragmentace volného místa ve fyzické RAM pak řeší khugepaged. Některé aplikace to umějí využít (např. MariaDB, Python, Apache).

Pokud máte slušný CPU, novější desku, funkční BIOS a třeba i novější grafickou kartu, lze zapnout IOMMU (což je dobré pro virtualizaci, když se přímo mapuje HW do virtuálu) a tím vyřešit HW komunikaci bez nutnosti mít souvislou fyzickou paměť.

Není to náhodou 2 roky starý problém (to o tom psal Oracle)? THP je v RHEL6/7, takže pochybuju, že by to nefungovalo. Díky neswapovatelnosti bych věřil že hugepages budou mít větší výkon (za předpokladu, že máte opravdu hodně RAM, tj. že nebude mít význam benefit uvolněním nepoužívané RAM pro cache/buffery).

Nebyl by nějaký odkaz na seriózní a aktuální benchmark THP/hugetables/bez?

Nojo, jenže to je 4 roky stará věc... stejně jako ostatní příspěvky, které se tím zabývaly a doporučovaly vypnutí THP. Od té doby je víceméně ticho... a tak to může být už jen urban legend (a Oracle si dělá vlastní memory managment, takže bych se nějakému vypínání nedivil, protože tím mohou řešit problémy/nedostatky i ve vlastním kódu, než že by to byl problém THP nebo výhoda neodstránkova­telnosti paměti).

Vzhledem k tomu, že THP je aktivita RH, který si to dal do jádra mimo oficiální strom, tak se dá předpokládat, že na tom intenzivně pracovali/pracují. Oni své nové věci vyvíjejí veřejně a dávají je nejdříve do RHEL, čímž si připraví půdu pro merge takové offtree záplaty do oficiálního Linusova stromu, zejména když je to hodně invazivní. Takhle byly merge pro ACL, SELinux atd.