Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
No mě by spíš zajímalo, jak se současné systémy vyrovnají s tím, že v paměti už něco je - jak zjistit, že to co tam je má smysl nechat, nemazat a nějak to zprovoznit :)
Treba v Linuxu takto:
https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt
Podobně jako při STR (suspend to RAM), jediný rozdíl je, že se bude moct vypnout napájení pamětí.
No, kdyby byl rok 2004, tak řeknu, že se vyvine nové rozhraní/sběrnice, která prostě nebude dynamicky obnovovat obsah pamětí, ale bude pouze zasílat rozdílové data. Problém je, že dneska jsou paměťové řadiče "zadrátovány" v CPU, takže se musí pracovat s tím, co je. Zároveň pochybuji, že by se intelu/AMD vyplatilo vyrábět odlišná CPU - s jiným řadičem, byť i pravděpodobně jednodušším (zabírá to prd místa, tak by to posléze zabíralo menší prd místa).
Možná s časem, pokud se tato technologie fakt prosadí a smažou se rozdíly této paměti oproti DRAM, ale to se podle mne nestane. Zatím je to dost malé, relativně pomalé a hlavně drahé. Stejný důvod, jako proč se nepoužívají SRAM, akorát tam je to cenou asi ještě o kus "dál".
Jinak k detekci přemazávání dat, očekávám, že to bude mít nějaký obslužný řadič, tedy že paměť nebude "hloupá" hromada pamětí, ale bude tam nějaký další obvod a pravděpodobně i paměť, kde se to bude celé inteligentněji řídit. Ostatně, nvdimm paměti jsou taky patřičně "ochytřeny".
S tím se už dávno vyrovnaly.
V RAM vždycky „už něco je“, tenhle problém musely řešit operační systémy už od začátku počítačů.
Jestli spravne chapu obrazek a doprovodny text, tak myslim, ze k zadnemu zjendoduseni nedojde, jak pise David Jezek, naopak dojde k dalsimu zesloziteni a prida se dalsi typ pameti (nebo dalsi vrstva pameti), kde se budou ukladat data mezi tim, co dnes chapeme jako RAM a volatilni pamet. To mi jako zjednoduseni moc neprijde
Proc neudelat jednu obri pamet, ktera bude pristupna jako disk, zaroven jako RAM a zaroven treba jako pamet pro GK? Ano chapu, ze pomer velikost/vykon bude na zacatku tristni, ale muze se to zlepsovat
Teoreticky je to pěkný koncept, prakticky by to byl dokonalý způsob jak tu technologii pohřbít - kvůli poměru cena/výkon by prodeje byly mizivé. Nejdřív je holt třeba na tom složitém zapojení technologii doladit, dosáhnout nějakých rozumných objemů výroby a teprve až se to finančně i výkonnostně vyplatí přejít na unifikovaný model. V byznysu se fakt nehraje na technickou dokonalost - spousta vynikajících technologií co byly převálcované méně dokonalými, ale líp prodejnými alternativami a skončily v propadlišti dějin by mohla vyprávět
Protože rychlá paměť (u vrcholu pyramidy) je drahá (cena 1TB DDR4 je cca 200000Kč a 1TB HDD je cca 1000Kč). Kromě toho GPU a CPU mají odlišné požadavky na propustnost (GPU využije řádově větší propustnost paměti než CPU) a latence (tady zase che CPU menší). Kromě toho když má k jedné paměti přístup více zařízení, tak to zpomaluje (musí se udržovat koheze cache).
Myslím, že cachování pořád není vyloučeno a že tou "jednou obří pamětí" byl rozuměn adresní prostor, nikoli že fyzicky budou všechny ostatní paměti zrušeny.
No tak to by bylo ale obrovské zesložitění současného stavu. Už jen takový malý problémek jako hotswapování jak by se řešil? Kdyby někdo chtěl mít softwarový RAID tak jak by se to z hlediska toho jednotného adresního prostoru chovalo? No ale hlavně - každá oblast má jiné požadavky. Pro paměť si OS udržuje tabulku stránek, kde je uloženo který proces tam ma právo na zápis, exekuci,... Na disku jsou práva řešená zcela jinak.
A co by se vyřešilo? Vždyť pro spuštění programu bys musel stejně načíst data z pomalé části adresního prostoru do rychlé.
Zkrátka idea sjednocování je hezká. Ne vždy ale dává smysl :) Něco jako dělat všude cesty s železniční tratí a trolejí a vodním kanálem aby mohlo všude dojet všechno ;-)
> No tak to by bylo ale obrovské zesložitění současného stavu.
Mam pro tebe dobrou zpravu - neni to sezloziteni soucasneho stavu, ono totiz to je presne soucasny stav :) Uz dobrych dvacet+ let, alespon na Unix/Linuxech. Kazdy proces ma vlastni virtualni adresni prostor, do ktereho si muze namapovat soubor nebo klidne cely disk. Viz: https://linux.die.net/man/2/mmap
> Už jen takový malý problémek jako hotswapování jak by se řešil?
Naprosto stejne jako hotswapovani PCI a hotswapovani USB. Kdyz nekdo vytahne USB klic zatimco nad nim nejaky proces cte/zapisuje, dostane signal a konci. Nebo sis snad myslel ze tyhle drobnosti nejsou v kernelu davno osetreny ?
> Kdyby někdo chtěl mít softwarový RAID tak jak by se to z hlediska toho jednotného adresního prostoru chovalo?
Software RAID resi jina - nizsi vrstva v kernelu. Tudiz z pohledu programu se to chova uplne stejne jako kdyz si zapisujes do souboru na RAIDu klasickym write/read.
> Na disku jsou práva řešená zcela jinak.
Ani ne, proces ma pravo na cteni/zapis/spousteni stranek, a (v unix / linuxu) jsou prava na disku cteni/zapis/spousteni souboru. Krom zopar specialnich bitu a pripadu, ale to se resi flagy v mmap().
> A co by se vyřešilo? Vždyť pro spuštění programu bys musel stejně načíst data z pomalé části adresního prostoru do rychlé.
Ano musel. Vyresilo se to, ze program se nepotrebuje starat o cache, protoze o cachovani zapisu a cteni se stara jadro. Vy proste pisete do / ctete z pameti a o zbytek se nestarate. Mimo jine je to daleko efektivnejsi nez mit vlastni cache v programu. Nepotrebujete se starat o balancovani velikosti cache vaseho programu (aby jste nechal misto ostatnim programum), postara se o to automaticky kernel (ktery navic umi vyuzit veskerou volnou pamet jako cache).
> Zkrátka idea sjednocování je hezká. Ne vždy ale dává smysl :)
Tahle dava perfektni smysl. A par dost znamych a pouzivanych programu ji vyuziva naplno (trebars PostgreSQL a Varnish).
BTW vsechny exace a kniznice v linuxu jsou pri spousteni nacteny pres mmap(). Mimo jine to znamena, ze kazda kniznice je nactena jenom jednou, i kdyz mate pustenych tisic programu ktere ji pouzivaji. Kdyby kazdy program pouzival read() pro nacteni kniznic, mel bys v pameti kopii kodu te kniznice pro kazdy pusteny program, coz je tak trochu brutalni plytvani pameti.
Myslím, že to mapování není striktně nutné, ale jiné řešení (třeba podobné jako deduplikace stránek v hypervizorech) by zřejmě vyžadovalo jinou podporu ze strany jádra OS (kterou ovšem některé OS už tak jako tak mají).
"No tak to by bylo ale obrovské zesložitění současného stavu."
Tak to je asi otázka úhlu pohledu. Z pohledu aplikačního SW to klidně může být zjednodušení.
"Už jen takový malý problémek jako hotswapování jak by se řešil?"
Podpora OS?
"Kdyby někdo chtěl mít softwarový RAID tak jak by se to z hlediska toho jednotného adresního prostoru chovalo?"
Opět, podpora OS?
"No ale hlavně - každá oblast má jiné požadavky. Pro paměť si OS udržuje tabulku stránek, kde je uloženo který proces tam ma právo na zápis, exekuci,... Na disku jsou práva řešená zcela jinak."
To je irelevantní, prostě by tam nebyl disk a byly by tam běžné nediskové prostředky ochrany, které by plnily stejnou roli. Pokud například u částí paměti můžete řešit, zda se dají spouštět nebo ne, a u "částí disku" (souborů) řešíte totéž, pak je logické, že když adresový prostor sjednotíte, nebudete totéž v jednom prostoru dělat dvěma různými způsoby.
"A co by se vyřešilo? Vždyť pro spuštění programu bys musel stejně načíst data z pomalé části adresního prostoru do rychlé."
Třeba níže jsem zmiňoval "nativní" formát dat bez nutnosti překódování. Výborné pro AllegroCache a jiné podobné databáze. Pouhé cachování je přitom transparentní operace.
Myslim ze ork myslel fyzicky jednu pamet, ono totiz jeden adresni prostor uz davno existuje. A odpoved kterou dal tomo je naprosto presna - penize a odlisne pozadavky.
BTW nedavno jsem videl prednasku nekoho z HP presne o tomhle tematu, a 5 minut na zacatku se rozplyval, jak disky + ram jsou evil a jak NVDIMM tohle cele uzasne zjednodusi. Dalsich 40 stravil tim, ze popisoval jak by to cele vypadalo v kernelu, a vypadalo to zhruba stejne jednoduche jako vesmirna lod :) myslim, ze ironie temhle lidem unikla..
"Myslim ze ork myslel fyzicky jednu pamet, ono totiz jeden adresni prostor uz davno existuje."
Jako že když uděláte mmap(2) přes celý disk? To sice technicky můžete, ale kdo to v praxi dělá? Navíc s běžným blokovým zařízením to až tolik užitečné není.
A co to vlastně je "fyzicky jedna paměť"? L1-L3 cache se do toho snad nepočítá? A co "L4 DRAM" v jiných slotech, třeba? To by bylo nutné nejprve ujasnit.
> To sice technicky můžete, ale kdo to v praxi dělá?
jak sem psal vyse, dela to kuprikladu PostgreSQL a Varnish. Ne nad /dev/diskem spis nad soubory (tam je to mnohem vic prakticke). V pripade PostgreSQL jsou ty soubory obrovske (cela databaze klidne pres vicero disku). Navic se mmap() dela pri spousteni vsech programu a nacteni kniznic. Tudiz data s kterymi pracuje program jsou ve stejnem virtualnim AS jako samotny kod programu.
> A co to vlastně je "fyzicky jedna paměť"?
Jeden druh pameti (ne cache) pripojen pres jednu sbernici, ktery by obsahoval jak trvale ulozena data, tak "pracovni oblast". Takovej ideal ktery se nekteri snazi dosahnout, ale jak bylo receno, je to neprakticke. Teoreticky by to slo udelat s NVDIMM ale imho prakticky to je nepouzitelne.
"jak sem psal vyse, dela to kuprikladu PostgreSQL a Varnish. Ne nad /dev/diskem spis nad soubory (tam je to mnohem vic prakticke). V pripade PostgreSQL jsou ty soubory obrovske (cela databaze klidne pres vicero disku). "
Tak tam jde o něco (účelem) maličko jiného, než co jsem měl na mysli já. :)
"Jeden druh pameti (ne cache) pripojen pres jednu sbernici, ktery by obsahoval jak trvale ulozena data, tak "pracovni oblast". Takovej ideal ktery se nekteri snazi dosahnout, ale jak bylo receno, je to neprakticke."
Nemyslím, že je to nepraktické, pokud se to správně použije. Problém je v tom, že jen málo softwarových architektů má zkušenosti s takovýmto návrhem (který se asi nejčastěji používá v objektových databázích, a těch zase moc není).
> Nemyslím, že je to nepraktické, pokud se to správně použije.
Myslel jsem neprakticke hlavne z hlediska vyrobnich nakladu hardwaru.
Vyrobit hardware ktery je levny a ma obrovskou kapacitu je jednodussi a mnohem levnejsi, nez napr. vyrobit hardware ktery je to vsechno + brutalne rychly + nonvolatilni. Nemyslim ze tohle se nejak brzy zmeni. Navic latence a propustnost jdou proti sobe. Proste cim vic pozadavek na to klades najednou, tim drazsi to bude ve vysledku. Ted mame spoustu druhu pameti, kazda z nich je dobra v 1-2 vlastnostech, a cele je to poskladane tak ze to bezi relativne dobre za dobrou cenu. Kdyby clovek chtel jedinou pamet v celem PC, pak musi to byt rychle jako DRAM, kapacitne jako HDD, nizke latence, vysoka propustnost, a cenove prijatelne. Nevidim moc realisticky, ze se tohle nekomu povede nejak brzy...
> softwarových architektů má zkušenosti s takovýmto návrhem
Problem je taky ten, ze IMO tenhle navrh neni uzasny vselek, za ktery ho vydavaji. Mel by smysl, kdyby programy vyuzivaly vsechny druhy pameti zhruba stejne, ale IMO je velmi malo programu ktere to dela. Vetsina vyuziva jen 1-2 aspektu pameti naplno. Napr: hry potrebuji extremne vysokou propustnost (GPU) ale nepotrebuji terabajty kapacity, databaze je na tom presne naopak. Akonahle bude "jedina pamet" v kteremkoliv aspektu horsi nez nektery soucasny druh pameti, bude obrovska skupina uloh pro ktere si zakaznik postavi levne PC, ktere ten novy koncept hrave trumfne cenou i vykonem. Tudiz IMO jedine pro nektere specificke ulohy, jinak silne overrated.
K dokonalému využití takovéto paměti by bylo pravděpodobně nutné napsat zcela nový software (třeba databáze najednou nebudou muset "balit" data do čtyřkilobajtových bloků). Takže nejspíše k prvním aplikacím takovéhoto konceptu dojde ve specializovaných řešeních.
„Proc neudelat jednu obri pamet, ktera bude pristupna jako disk, zaroven jako RAM a zaroven treba jako pamet pro GK?“
To je jednoduché: Na to potřebujete paměť, která bude rychlostí na úrovni RAM, nebude vyžadovat napájení a poměr cena/kapacita bude na úrovni harddisků.
A taková technologie tu zatím nebyla.
„Ano chapu, ze pomer velikost/vykon bude na zacatku tristni, ale muze se to zlepsovat“
Jenže jakou to má reálně výhodu?
Z toho, že zařízení má jen jednu paměť, uživatel přímo nic nemá. Dokud rychlost nebude na úrovni DRAM, celé zařízení bude pomalejší a bude mít malou kapacitu paměti (proti zařízení s DRAM + úložištěm). Nebo pomalejší, přijatelnou kapacitu, ale drahé.
Jinak takhle nějak to měly staré smartphony, třeba moje Nokia E52. Ta má (kromě systémové ROM) jen jednu paměť.
Jenže jak se z telefonů stávaly mini-počítače a byl potřeba vyšší výkon, tohle řešení prostě nestačilo.
Rozhodne bude prednosti 3D XPoint NVDIMM pametovych cipu/modulu jejich energeticka nezavislost/nevolatilita, data proste zustanou po vypadku proudu dale v modulech a bude s nimi nasledne dale/okamzite se po zotaveni systemu ze šoku mozno nakladat.
Jestli to bude vykonem DDR4 plne rovnocenne, vidim to na moznost vytvareni malych 32/64/128GB SSD NVDIMM bloku/ulozist cim by rapidne vzrostli moznosti nejenom u vyuziti takto masivni velikosti operacni pameti jako takove ale vznikla by tu i dostatecna pred-cache(masivni na urovni 4/8 oddelenych pametovych kanalu jako u AMD Epyc), proste "hruba" data by se nemusela presouvat mezi SSD a NVDIMM/RAM, ale byli/sedeli by primo v operacni pameti a az nasledny konecny vysledek by dle prani zadatela/uzivatela putoval na externi pametove uloziste pripojene skrze M.2/S-ATA Express/NVMe-H slot.
Co se tyka bezpecnosti dat na nevolatilnich VDIMM modulech, tak jiste si budou moduly kazdy zvlast provadet autorizaci k pristupu na urovni kodu ktery se bude nachazet zapsan na konkretni zakladni desce v UEFI/SecureBoot v urcitem algoritmu, kazda nova instalace OS bude vyzadovat automaticke vygenerovani/rucni zadani noveho overovaciho kodu, sem toho nazoru ze 3D XPoint NVDIMM ponesou registracni cip jak ho zname z DDR dnes a s tim tu bude pritomna tez i ECC korekce/TRIM.
Ono to nakonec vypada ze to bude dostupno az s prichodem DDR5 slotu :) Takze hura.. kupujte vsichni DDR4 servery, ktere pak vyhodite :P
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.