Intelin Sapphire Rapids tulee tukemaan myös HBM-muisteja

[Kaotik]

Intel on julkaissut 42. version ISA Extension Reference -oppaastaan. Opas varmistaa tulevien Sapphire Rapids -palvelinprosessoreiden tukevan Linear Address Masking -ominaisuutta ja HBM-muisteja.
Toistaiseksi ei ole tiedossa, tuleeko HBM-muisteista standardiominaisuus Xeoneissa tai edes tullaanko ne kytkemään suoraan itse prosessoriin, sillä Intelin mallistoon kuuluu myös Xeon-prosessoreita, joissa samaan paketointiin on integroitu muita kiihdyttimiä.
Linear Address Masking taas mahdollistaa 64-bittisen lineaarisen osoiteavaruuden osoittamattoman osuuden hyödyntämisen metadatan tallentamiseen. Prosessorit osoittavat lineaarisesta osoiteavaruudesta tyypillisesti 48 tai 57 bittiä.

Lähteet:

Intel Preparing Linear Address Masking Support (LAM) - Phoronix

www.phoronix.com

.

 

[hkultala]

Linear Address Maskingista:

Tämä siis tarkoittaa vaan sitä, että yksi x86-64-arkkitehtuurin erikoisuus, korkeiden bittien "väärinkäytön" kielto perutaan. Kyseessä ei ole mikään "uusi teknisesti hieno ominaisuus" vaan päin vastoin tämä on vain yhden ominaisuuden poiskytkeminen ja paluu yksinkertaisempaan ja luonnollisempaan toimintaan.

Esim. Amigassa ja alkuperäissä macintoshissa oli 68k-prosessori, jossa rekisterit oli 32-bittisiä, mutta muistiosoitteet oli vain 24-bittisiä (maksimi muistiavaruuden koko 16 megaa), ja ylimmät bitit vaan ignorattiin muistiaccesseja tehdessä. Koodarit keksivät, että pointterien ylimpään kahdeksaan bittiinhän on kiva tallettaa jotain metadataa, kun ne ignorataan muistiaccesseja tehdessä, ja monet softat sisälsivät tällaisia kikkailuita.

No, joitain vuosia myöhemmin tuli sitten 68020-prosessori, jossa muistiosoitteet oli täydet 32 bittiä, ja näitä temppuja käyttävät ohjelmat eivät sitten toimineetkaan sillä.

AMD x86-64sta speksatessaan päätti, että vältetään tällaiset yhteensopivuusongelmat kieltämällä tällainen kikkailu, ja kun x86-64een speksattin 48-bittiset virtuaaliosoitteet 4-tasoisilla sivutauluilla, samalla myös määriteltiin, että muistiosoitteen ylimpien 16 bitin on pakko olla samat kuin se ylin varsinainen osoitebitti.

No, jotkut softat KUITENKIN väärinkäyttivät näitä ylimpiä osoitebittejä. Ne vaan sitten kikkailivat siten että ennen kuin dataa accessoitiin sen pointterin kautta, se ylimpien bittien metadata kopioitiin muualle ja ne ylimmät bitit vekslattiin siihen speksin vaatimaan muotoon, mihin sitten kului ylimääräisiä käskyjä, mutta jos virtuaaliosoite onkin oikeasti yli 48-bittinen, softa hajoaa.


ARM speksatessaan 64-bittistä ARMv8 käskykantaa päätyi ratkaisuun, että korkeilla biteillä kikkailua ei kielletä, siinä virtuaaliosoitteen koko on virtuaalimuistisivujen koosta ja sivutaulujen tasomärästä riippuen joko 39,42,48, 52 tai 56 bittiä. Ja esim Apple heti hyödynsi tätä virtuaalikoneidensa/tulkkiensa muistinhallinnassa.


Intel laajensi sivutaulut 4-tasoisista 5-tasoisiksi Ice Lakessa, jolloin virtuaaliosoiteavaruus kasvoi 48sta 57 bittiin. Tämä on kuitenkin uusi toimintatila joka käyttiksen pitää erikseen kytkeä päälle, jos käyttis ei tätä kytke päälle, virtuaaliosoitteet on edelleen 48-bittisiä.

Nyt Intel käytännössä toteaa, että ylimmillä biteillä kikkailun kieltäminen oli huono idea. Kun sitä kikkailua kuitenkin tehdään ja siitä on selvä suorituskykyhyöty joissain tilanteissa, sallitaan sen tekeminen sitten täydellä nopeudella ilman lisäkikkailua. Eli ylimpien 7 tai 16 bitin ei enää tarvikaan olla samat kuin se ylin varsinainen osoitebitti.

Mutta ainakin niiden softien, jotka hajoaa 5-tasoisessa tilassa, määrä on todella paljon pienempi, kun tämä sallittiin vasta nyt. Ja toisaalta, kun nyt mennään 57 bittiin niin sillä selvitään seuraavat parikymmentä vuotta, ennen kuin sivutauluihin pitää tuoda kuudes taso ja osoitteet laajentaa täyteen 64 bittiin, eli jos tästä on jotain yhteensopivuusongelmia tulossa, ne tulee vasta 2040-luvulla. Ja onko x86 enää silloin elossa?

 

[Hannibal]

Kassos! Tiedätkö miten Zen3 hoitaa tämän asian tällä hetkellä, eli menevätkö isot valmistajat nyt hetken aikaa eri suuntiin?

 

[hkultala]

Kassos! Tiedätkö miten Zen3 hoitaa tämän asian tällä hetkellä, eli menevätkö isot valmistajat nyt hetken aikaa eri suuntiin?

Zen3 tukee vain 48-bittistä virtuaalimuistiavaruutta, ja vaatii että kaikki 16 "käyttämätöntä" ylimmäistä bittiä on samat kuin 17. ylimmäinen bitti.

Mutta eiköhän AMD pian
1) lisää tuen 5-tasoisille sivutauluille (ehkä zen4ssa?)
2) poista tuon vaatimuksen että 16 ylimmäristä bittiä on samat kuin 17. ylimmäinen bitti (ehkä zen5ssa?)

Ei tässä varsinaisesti voi puhua eri suuntiin menemisestä, lähinnä että Intel poistaa tämän vaatimuksen aiemmin kuin AMD.

 

[Griffin]

Mitkäs on nyt suhtelliset nopeudet? Toisaalta siirtonopeus ja toisaalta ansimmäisen tavun viive, jos verrataan
Intelin nykysykupolven
L1
L2
L3
Se Intelin oma chippi, joka oli välillä boostimuistina muutamassa prossussa..
Oletettu HBM(3?) ratkaisu, esim 2:lla pinolla ja leveällä väylällä prossuun..

 

[zepi]

1TB muistia tarvitsee 40-osoitusbittiä ja on jo "standardikamaa" serverissä. 1.5TB, 2TB, 3TB ja 4TB servereitäkin on ihan yleisesti käytössä, eli 42-bittiä on jo käytössä.

8TB ja 16TB eli, eli 42-43 bittistä osoitusta tarvitsevat DDR5-kokoonpanot ovat tulossa tarjolle vissiin ensi vuonna?

 

[hkultala]

1TB muistia tarvitsee 40-osoitusbittiä ja on jo "standardikamaa" serverissä. 1.5TB, 2TB, 3TB ja 4TB servereitäkin on ihan yleisesti käytössä, eli 42-bittiä on jo käytössä.

8TB ja 16TB eli, eli 42-43 bittistä osoitusta tarvitsevat DDR5-kokoonpanot ovat tulossa tarjolle vissiin ensi vuonna?

Tässä puhuttiin virtuaaliosoitteista, ei fyysisistä muistiosoitteista. Virtuaaliosoitteissa on kyse siitä, kuinka suuren muistiavaruuden yksi prosessi voi nähdä, ei siitä, paljonko muistia koneeseen voi fyysisesti laittaa.

Servereissä tyypillisesti ajetaan suurta määrää prosesseja, mutta suurin osa niistä yksittäisistä prosesseista ei vaadi suurta muistiavaruutta. Suuren virtuaalimuistiavaruuden vaatii lähinnä jotkut tietokantapalvelimet, mutta ne haluaa sen vaikka fyysistä muistia olisi vähemmänkin, kunhan vaan käsiteltävä tietokanta on iso; Levyllä olevia tiedostoja voidaaan mmap()-systeemikutsulla mapatä näkyviin muistina, ja käyttiksen muistinhallinta huolehtii siitä, että siinä vaiheessa kun siitä luetaan jotain virtuaalimuistisivua, se sivu ladataan siinä vaiheessa levyltä.


Se, kuinka paljon fyysistä muistia tuetaan, ei näy käskykanta-arkkitehtuurissa, ja sitä tyypillisesti lisätään parilla bitillä mallisarjojen välillä, ja se voi aivan hyvin olla selvästi enemmän kuin virtuaaliosoitteiden koko.

 

[zepi]

Hypervisorin ei tarvitse osata osoittaa kaikkea muistia?

 

[hkultala]

Hypervisorin ei tarvitse osata osoittaa kaikkea muistia?

Hypervisor osaa aina osoittaa kaikkea muistia, riippumatta siitä, minkä kokoisia virtuaaliosoitteet on.

 

[Kaotik]

Mitkäs on nyt suhtelliset nopeudet? Toisaalta siirtonopeus ja toisaalta ansimmäisen tavun viive, jos verrataan
Intelin nykysykupolven
L1
L2
L3
Se Intelin oma chippi, joka oli välillä boostimuistina muutamassa prossussa..
Oletettu HBM(3?) ratkaisu, esim 2:lla pinolla ja leveällä väylällä prossuun..

Aika varmalla voinee väittää, että HBM-tuki on jotain tiettyä erillistä kiihdytinsirua varten ja esimerkiksi varsinaiset HBM-muistiohjaimet tullee olemaan tällä erillisellä kiihdyttimellä.
Sapphire Rapidsissa tulee samalla kuitenkin myös DDR5-tuki

 

[zepi]

Hypervisor osaa aina osoittaa kaikkea muistia, riippumatta siitä, minkä kokoisia virtuaaliosoitteet on.

Boldaukset eivät lisää ymmärrettävyyttä nyt kyllä yhtään.

Kaikki softat (käyttis mukaanluettuna) käyttävät virtuaaliosoitteita jotka prossun MMU mäppää hardis-osoitteiksi. Eikö hypervisorin virtuaaliosoiteavaruuden silloin pidä väkisinkin olla silloin vähintään yhtä iso kuin fyysisen avaruuden, vai onko käytössä joku paging systeemi? Hypervisor ei käsittääkseni tee sinänsä muistiosoitusta VM:ien puolesta, vaan se päästää guestin muistiosoituspyynnöt suoraan MMU:lle.

En kyllä tunne VT-x, EPT ja SLAT teknologioita yhtään.

 

[Griffin]

Aika varmalla voinee väittää, että HBM-tuki on jotain tiettyä erillistä kiihdytinsirua varten ja esimerkiksi varsinaiset HBM-muistiohjaimet tullee olemaan tällä erillisellä kiihdyttimellä.
Sapphire Rapidsissa tulee samalla kuitenkin myös DDR5-tuki

Olisiko siinä nyt mitään järkeä?
Prossu ja ko siru eivät voisi keskustella sitten nopean muistin välityksellä..

 

[hkultala]

Boldaukset eivät lisää ymmärrettävyyttä nyt kyllä yhtään.

Kaikki softat (käyttis mukaanluettuna) käyttävät virtuaaliosoitteita jotka prossun MMU mäppää hardis-osoitteiksi. Eikö hypervisorin virtuaaliosoiteavaruuden silloin pidä väkisinkin olla silloin vähintään yhtä iso kuin fyysisen avaruuden, vai onko käytössä joku paging systeemi? Hypervisor ei käsittääkseni tee sinänsä muistiosoitusta VM:ien puolesta, vaan se päästää guestin muistiosoituspyynnöt suoraan MMU:lle.

Sen mäppäyksen virtuaaliosoitteiden ja fyysisten osoitteiden välillä päättää käyttis/hypervisor, ei rauta.

Käyttis/hypervisor tekee sivutaulut, rauta muuttaa osoitteet sen mukaan miten sivutauluissa lukee.

Rauta vain tottelee, miten käyttis/hypervisor käskee sen toimia.

Se käyttis/hypervisor pystyy vaihtamaan sitä, mitkä 48 bittiä osoiteavaruutta on suoraan käytettävissä yhdellä rekisterinkirjoituksella, joka vaihtaa osoitetta päätason sivutauluun.

Sillä voi olla vaikka tuhansia erilaisia 48-bittisiä virtuaalimuistiavaruuksia joilla se yhteensä kattaa helposti vaikka yli 60 bitin verran fyysistä muistia, ja joiden välillä se pystyy vaihtamaan todella helposti ja nopeasti päästäkseen haluamaansa osoitteeseen (normaalistihan jokaisella prosessilla on omansa).

 

[love_doctor]

1TB muistia tarvitsee 40-osoitusbittiä ja on jo "standardikamaa" serverissä. 1.5TB, 2TB, 3TB ja 4TB servereitäkin on ihan yleisesti käytössä, eli 42-bittiä on jo käytössä.

8TB ja 16TB eli, eli 42-43 bittistä osoitusta tarvitsevat DDR5-kokoonpanot ovat tulossa tarjolle vissiin ensi vuonna?

Ihan teoreettisella tasolla osoitteiden ei ole kyllä pakko pystyä viittaamaan jokaiseen tavuun vaan esim. voidaan granulariteetti rajata kokonaiseen tai puolikkaaseen sanaleveyteen, jolloin jo säästää bittejä. Tuohon alignoinnin pakottamiseen on kylllä kielissä tukea. Ja toisestakin suunnasta voi kikkailla kuten esim. perinteisissä x86-koneissa ennen suojattua tilaa.

 

[hkultala]

Ihan teoreettisella tasolla osoitteiden ei ole kyllä pakko pystyä viittaamaan jokaiseen tavuun vaan esim. voidaan granulariteetti rajata kokonaiseen tai puolikkaaseen sanaleveyteen, jolloin jo säästää bittejä. Tuohon alignoinnin pakottamiseen on kylllä kielissä tukea. Ja toisestakin suunnasta voi kikkailla kuten esim. perinteisissä x86-koneissa ennen suojattua tilaa.

Pätee, jos tehdään uutta käskykanta-arkkitehturia. Mutta käytännössä tästä seuraisi aivan liian suuret ongelmat, että CPU-käytössä ei mitään järkeä, jossain hyvin erikoistuneessa DSPssä/ASIPissa voisi toimia, koska
1) 8-bittisten datatyyppien käyttäminen kävisi hyvin hankalaksi
2) Ziljoona softaa jotka olettaa että char on 8-bittinen hajoisi (C-kielen standardi sanoo, että sizeof(char) == 1).

Mutta x86:ssa osoitteet on aina tavuosoitteita.

Ja x86lla virtuaaliosoitteen rajoitetteet tulee virtuaalimuistisivujen koosta ja määrästä, ei kokonaisbittimäärästä. Se, että alin osoitebitti pudotettaisiin pois ei tällä rajoitteella muuttaisi osoitettavan muistin määrää yhtään mihinkään, koska se alin bitti on siellä sivun sisäisissä osoittessa joille ei muutenkaan tarvi mitään osooitteenmuunnosta tehdä.