Administrace komentářů

Ještě k tomu přímému připojení na paměťový řadič (do DIMM slotů): pokud jsou technologie RAM a Flash natolik rozdílné, případně vyžadují jiné časování, možná by byla řešením nějaká "sjednocující mezivrstva", která se pružně přizpůsobí obojímu (třeba umí obsloužit každý DIMM s jinými latencemi) - možná by na to stačila technologie FB-DIMM, která vyšla z módy po jedné generaci čipsetů... Údajně umí vyřizovat transakce i *paralelně*, protože je bufferuje...

Taky mě napadlo vyvést pro Flash extra sběrnici z north bridge, nebo pro ni udělat bridge na QPI/HyperTransport... ale zásadní společný problém je počet pinů navíc v pouzdrech čipsetu a/nebo procesoru. To je problém i při rozšiřování adresního prostoru obsloužitelného FSB. Není to tak docela čistě marketingová záležitost.

K tomu 2U DELLu - Xeony 5500 umí obsloužit 144 GB RAM v 9 DIMM slotech na každou CPU patici, při použití 16GB DIMMů... To je divočina...

A máte pravdu, že spousta technologických konvencí jede často "postaru setrvačností" Osobně si nejsem jistý, že by průchodnost a latence Flash pamětí byla bůhvíjaká výhra (ve srovnání s DRAM). Ale fakt je, že koukat na ně skrz SATA kanál tu latenci asi ještě trochu degraduje Nemluvě o nevýhodách "multiplexního přístupu" (Flash není přímo součástí adresního prostoru CPU).

Hehe... přemejšlím, jak by mohla vypadat organizace ukládání executable souborů do Flash paměti, odkud by se daly přímo spouštět. Při aktualizaci softwaru by vznikala fragmentace. Což by se ale dalo ošetřit stránkováním. Třeba kdyby nativní stránkování virtuální paměti CPU mohlo pasovat na stránkování Flash čipů. Což u dnešních procesorů a flashí není zdaleka samozřejmé... Ještě mě napadá, jestli při spouštění executable binárů není potřeba nějaká relokace adres, ale to by se možná dalo ošetřit architekturou OS (přesným schématem mapování user-space adresního prostoru jednotlivým procesům), možná by byla potřeba nějaká spolupráce na úrovni instrukční sady CPU...