Vlákno názorů ke zprávičce Intel pracuje na pětiúrovňové tabulce stránek od Palo - Viac ako 64TB som na tej stranke SGI...
-
To neni ani tak limit OS jako limit CPU. Kdyby CPU pouzivalo 64-bitovou adresaci (coz by clovek u 64-bitovyho procesoru cekal), tak by i bez strankovani moh adresovat 16 exabyte.
To na cem pracuji je ve skutecnosti jen berlicka typu PAE, ktera stejne jako PAE prestane byt aktualni az se adresovy prostor v CPU rozsiri. -
Původní 64bitové CPU od AMD používaly pro fyzickou adresu 40 bitů (rok 2000), takže bylo možné adresovat maximálně 1 TiB. Od roku 2007 je používáno 48 bitů (od AMD Family 10h, neboli K10), což je zmíněných 256 TiB (2^48), tj. i současný limit. Architektura AMD64/x86_64 však umožňuje použít až 52 bitů, což jsou ty 4 PiB, na které bude adresace posunuta (víc to nejde, zbylé bity jsou použity ve stránkovací tabulce). Intel tedy evidentně připravuje procesor, který bude používat na adresaci zmíněných 52 bitů. Buď již mají vzorové kusy nebo používají emulátor/simulátor, a proto programují softwarovou část podpory pro jádro Linuxu. Stejně to bylo při příchodu 64bitových CPU od AMD (podpora v jádře Linuxu byla dříve, než začal CPU vyjíždět z výrobní linky). Není to tedy obezlička jako PAE, nýbrž normální využití zbývajícího potenciálu 64bitové platformy AMD64/x86_64.
Pro využití všech 64 bitů by jeden záznam v tabulce stránek zřejmě kvůli současnému zarovnávání v RAM musel být 128bitový, což by bylo neúnosné plýtvání (na příznaky je použito 12 bitů, na 32bitové platformě to bylo 10 bitů). Může se však třeba změnit velikost stránky, což by s počty zamíchalo, ale zase by to rozbilo úplně všechno v jádře, aplikacích i hardware, který předpokládá velikost stránky 4 KiB.
-
hu (neregistrovaný)
ale zase by to rozbilo úplně všechno v jádře, aplikacích i hardware, který předpokládá velikost stránky 4 KiB.
Nemyslím, problém by byl se stránkami menšími než 4KiB, protože např. PCIe nevynucuje na menších oblastech žádná pravidla zarovnávání. Pár architektur s většími stránkami už v jádře je, minimálně SPARC s 8KiB.
-
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.
-
hu (neregistrovaný)
A jak to teda resej na tom SPARCu?
#define PAGE_SHIFT 13
http://lxr.free-electrons.com/source/arch/sparc/include/asm/page_64.h?v=4.7#L8 -
Trident (neregistrovaný)
Jak tedy vysvetlit implementaci na architekturach kde je page size vetsi nez 4kb? A co posledni patche pro ext4 na podporu huge pages?
Pokud je kod specificky pro x86 tak spatny/zastaraly, nezbyva vam chlapci kernelovi nez to prepsat. Casu na to bylo dost. Pokud je to napsano specificky na page size 4kb, tak je to napsano blbe.Cluster na disku nema vzdy 4kb. Zalezi na pouzitem filesystemu. Klidne 64kb nebo 128kb jsou bezne velikosti. Moderni filesystemy pouzivaji promennou velikost clusteru.
Zarovnavani velikosti clusteru fs na diskove bloky uz ztratilo vyznam davno ale to tady asi nema cenu probirat. -
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.
-
Tak ona vetsi velikost stranek (hugepages) tam jiz davno je a dokonce se v Linuxu pouziva, aby se usetrilo na TLB a o pak to dava o neco lepsi vykon:
arm64: 4K, 2M and 1G (or 64K and 512M with CONFIG_ARM64_64K_PAGES=y)
i386: 4K and 4M (2M in PAE mode)
ia64: 4K, 8K, 64K, 256K, 1M, 4M, 16M, 256M
ppc64: 4K and 16M -
Jenda (neregistrovaný)
> Pro využití všech 64 bitů by jeden záznam v tabulce stránek zřejmě kvůli současnému zarovnávání v RAM musel být 128bitový, což by bylo neúnosné plýtvání (na příznaky je použito 12 bitů...)
Proč by page table entry nemohl vypadat takhle?
12b flags : 52b adresa : 12 implicitních nul (velikost stránky je alespoň 4 KiB, proto dolních 12 bitů bude nulových)
(teda mně přijde, že už tak vypadá -- nebo těch 12 spodních nul není implicitních?)
-
Jenda (neregistrovaný)
Tak jsem otevřel AMD64 Architecture
Programmer’s Manual a on už takhle vypadá (akorát flagy jsou logicky na konci, tipuju že proto, aby šlo adresu vymaskovat a nemusela se posouvat). Takže by mělo stačit přidat šestou úroveň pagetables a můžeš mapovat opravdu všechno.Na druhou stranu mi není jasné, kde se tam bere ten limit na 2^52 B fyzické paměti.
-
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.
-
Jenda (neregistrovaný)
ByCzech: Měl jsem za to, že počet drátů je u různých CPU různý a třeba desktopová CPU jich mají klidně jenom 32. To není limit architektury, ale toho, jak to zrovna výrobce implementuje.
ded.kenedy: Příznaků ve stránkovací tabulce je 12, adresa ve stránce je taky 12, takže to by mělo být v pohodě. V CR3 je horních 12 bitů reserved a na nic se nepoužívají.
Milan Keršláger: Ano, jak PTE na amd64 vypadá, jsem si přečetl v manuálu. Pořád z toho (ani tvého komentáře) nevidím ten důvod, proč tím nejde adresovat 2^52 stránek, tedy 2^64 bajtů fyzické paměti.
-
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 :-)
-
Yenya (neregistrovaný)
K poslední větě: phys_to_virt ano (pokud nepočítám 32-bitový systém s víc než 896 MB RAM a CONFIG_HIGHMEM). U bus_to_virt je to tuším složitější, můžou do toho vstupovat různé IOMMU po cestě. Nevím jestli se dnes vůbec bus_to_virt používá, já jsem to naposled použil u ISA DMA driveru :-). Řekl bych, že dnešní ovladače si o přístup k PCI adresnímu prostoru říkají přes ioremap().
-Yenya
-
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/include/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_virtTakže nejsem o moc moudřejší, než jsem byl :-) Zřejmě rovnost bus=phys kdysi platila, ale dnes už nemusí nutně platit...
-
Trident (neregistrovaný)
Dekujeme ze nas zasobujete vasimi vypatlaninami.
1. Kazdy slusne napsany system ktery jede na vice platformach resp. designeri o tom uvazovali je napsany tak aby podporoval vice page size. Mozna to nekoho prekvapi, ale moderni CPU (zejmena eintopf typu AMD64) nejsou jen hodne vykonne mikrokontrolery, takze i u jedne architektury se uz pomerne dlouho mixuje i vice page size.
2. Od dob pentia mame 4MB page(S bit i flagu page) a nektere 2MB(tusim architektury co podporuji PAE).To by nemela byt pro pana tedy zadna novinka. AMD64 podporuje i 1GB page size coz uz je zajimave pokud pracujes s all in memory architekturami.
3. V linuxu lze zapnout huge pages(zavisla na nastaveni v systemu/architekture), Podporu techto veci lze najit u jinych architektur ktere podporovaly linux jeste davno pred tim nez byla nejaka AMD64. Mozna proto ze nebylo zbyti:)
3. Fakt 4kb page size nikoho dneska nevytrhne. Mozna v dobe 386.
4. Kde jsi prisel na to ze moderni HW je zavisly na 4kb page size?
5. Kde jsi prisel na to ze to rozbije aplikace? Aplikaci je to jedno pokud nepouziva specialni alokacni syscally na velke page size pro specificky system. To uz by ta appka musela byt hodne debilne napsana aby natvrdo pocitala treba se 4kb? Aplikace nepisou jen matfyzaci. Od ceho ma getpagesize? Lidi co napsali POSIX specifikace asi byli tak hloupi a na to zapomneli? Wake up! Tento problem tu uz byl davno pred linuxem a pred x86-32. Myslis ze na to inzenyri 30 let dlabali? -
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é.
-
hu (neregistrovaný)
To není tak úplně pravda. Jednak existuje IOMMU, jednak nějakou formu scatter / gather DMA podporuje prakticky každé zařízení a standard, kde jde o propustnost, namátkou AHCI, NVME... a hromada jiných PCI(e) busmasterů (třeba video framegrabberů), které mají vlastní implementaci.
-
...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?
-
Ivan (neregistrovaný)
Odkaz nemam, ze kdyz jsem zjistoval okolnosti tak jsem zjistil, ze zakazat THP doporucuje kde kdo. "Klasicke" HP jsou neswapovatelne. Coz je pro databaze Oracle anebo PostgreSQL vyhoda. Nikdo nechce buffer cache odlozit na disk a kernel ma mene prace s prochazenim stranek. Uz predtim se daly shared memory segmety alokovat jako neswapovatelne, ale nebylo to zapnute by-default.
THP pridava moznost odkladat(swapovat) HP na disk. To pred tim asi neslo. Navic v pripade RAC nektere procesy bezi prod rootem a maji "real-time" prioritu. Tyhle procesy preposilaji zpravy, a jsou citlive na latence.
MOS has a new alert 1557478.1 that says "Because Transparent HugePages are
known to cause unexpected node reboots and performance problems with RAC,
Oracle strongly advises to disable the use of Transparent HugePages."Myslim, ze minimalne u Oracle jeste leta tu bude doporuceni: pouzivat HP, vypnout THP.
Pokud jde o nejakou analyzu, tak se mi podarilo najit jen tohle:
http://structureddata.org/2012/06/18/linux-6-transparent-huge-pages-and-hadoop-workloads/Zminuje se tam jeden konkretni neverejny bug na RHEL.
-
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ánkovatelnosti 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.
