No nyt asiaa voi yksinkertaistaa
... tämä ei ole "vain yksinkertaistamista" vaan täysin toimimattoman asian ehdottamisen vaihtaminen toimivan, mutta suorituskyvyn kannalta hiukan huonohkon asian ehdottamiseksi.
että jätetään se microtag erikseen, eli onko ongelmaa sisäistää että jos cachelinja on tagattu sekä täydellä virtuaalisella että täydellä fyysisellä tagilla virtuaalinen osuma cacheen riittää varmistamaan osuman 100% varmuudella. Tämä on ollut ihan esimerkki oppimateriaalissa, ko. tekniikkaa lienee aikanaan jopa käytettykin, tuplataggaus vain jossain vaiheessa katsottiin turhaksi.
Vai onko siinä vielä jotain mitä et käsitä, miksi haluaisit tehdä vielä osoitemuunnoksen ja tarkistaa fyysisen tagin?
Osuman tarkastaminen pelkällä
täydellä virtuaalisoitteella tosiaan
toimii mutta siinä on paljon hidastavia ja hankaloittavia tekijöitä, mm:
Virtuaalisten ja fyysisten osoitteiden välinen mäppäys ei ole vakio ja universaali, useasta eri syistä:
1)
Zen tukee SMT:tä. Ja SMT, vaikka tulee sanoista "Simultaneous MultiThreading", tarkoittaa se oikeasti kahden erillisen PROSESSIN ajamista siellä prosessoriytimellä, ei pelkästään saman prosessin eri säikeiden.
Molemmilla virtuaaliytimillä voi siis olla aivan eri virtuaalimuistimappaykset. Mikäli L1D tagattaiisin virtuaaliosoitteella, sinne pitäisi laittaa bitti, joka kertoo, kumman virtuaaliytimen virtuaaliosoitteista on kyse, ja julistaa huti, jos tämä bitti sanoo, että tämä on toisen virtuaaliytimen dataa. Tähän asti ei kuulosta pahalta, yksi lisäbitti on halpa, MUTTA:
Tästä seuraa se, että jos meillä onkin siellä kaksi SAMAN PROSESSIN säiettä, joilla on sama virtuaaliosoitemäppäys, ja jotka jakavat (käytännössä kaiken) datansa, sitten toisen virtuaaliytimen välimuistiin lataama data ei näkyisi toiselle, ja meillä tulisi pahasti L1D-huteja seuraavissa tilanteissa:
1a) Molemmat lukee samaa dataa joka tulee muualta, tämä pitäisi duplikoida molemmille säikeille. Paitsi että hups, siellä on se logiikka joka kieltää saman fyysisen osoitteen olemisen samassa välimuistissa kahteen kertaan. Eli tilanteessa jossa molemmat yrittävät lukea samaa read-only-dataa, tämä data flushataan jatkuvasti toiselta, ja tästä seuraa todella pahaa ping-pong-efektiä ja hidastelua.
1b) Toinen säie kirjoittaa jotain ja sen jälkeen toinen säie lukee sen. Koska tämä olisi tägätty väärällä ydin-id-bitillä, toinen ei voisi lukea tätä suoraan, vaan tulisi huti ja data pitäisi kierrättää L2-kakun kautta.
Erityisesti tilanne 1a olisi oikeasti paha/usein esiintyvä ongelma. Saman softan eri säikeiden välillä on usein paljon dataa, jota moni säie (vain) lukee.
2)
Context switchit
Mikäli käytettäisiin virtuaalisia TAGeja, pitäisi context switchin yhteydessä flushata kokonaan sen virtuaaliytimen L1D-välimuisti. Vaikka siellä toisessa säikeessä viihdyttäisiin hyvin vähän aikaa ja alkuperäiseen säikeeseen palattaiisin heti takaisin.
Esim jotkut keskeytyskäsittelijät aiheuttaisi tästä huomattavasti lisää hidastumista, niissä kun tyypillisesti tehdään vain jotain todella pientä todella nopeasti, mutta keskeytyksiä voi tulla aika suuria määriä aikayksikköä kohden, jos esim on sekä levy- että verkkoliikennettä menossa.
Intelin prosessorit on kuitenkin viimeiset kymmenisen vuotta tukeneet Process Context ID (PCID)-toimintoa, jolla voisi käytännössä kertoa, minkä prosessin virtuaaliosoitteista on kyse, ja jos tagiin lisättäisiin virtuaaliosoitteen lisäksi PCID (joka toki sitten tekisi siitä tagista isomman, ja lisäisi virrankulutusta ja tarvittavan vertailijan kokoa), suurin osa näistä yllä mainitsemistani ongelmista voitaisiin ratkoa hinnalla että TAG olisi vain 12 (tai siis 11) bittiä suurempi.
PCID ei kuitenkaan ollut tuettu Zen:ssä tai Zen2ssa, AMD lisäsi sille tuen vasta Zen3een. Ja softan puolesta taas tuki tuli esim. Linuxille vasta vuoden 2017 lopulla.
Mikäli Zenissä olisi virtuaalitagatyt, välimuistit, sinne olisi kyllä haluttu lisätä myös PCID-tuki näiden yllämainitsemieni ongelmien välttämiseksi (ja agitoida käyttikset tukemaan sitä).
Ja syy, miksi PCID-tuki on nyt tullut Zen3een lienee se, että se mahdollistaa paljon nopeamman toteutuksen tietyille suojamekanismeille joitain sivukanavahyökkäyksiä vastaan.
Ja niin, virtuaaliosoitteet on X86-64lla 48 bittiä(ja sen vaadittavan virtuaaliydin-idn kanssa siis 49 bittiä, eli virtuaalisoite-TAG olisi 37 bittiä. (PCIDn kanssa olisi sitten 48 bittiä, mutta tiedetään että sitä ei ole tuettu)).
DRAMin maksimikapasiteetti Zenillä on 41 bitin verran, ja jos sen päälle pitää vähän muistia varata muistimäpätylle IOlle jota saa kakuttaa, tarkoittaisi se 42 bittiä, eli fyysisillä osoittella toimivalle TAGille riittäisi 30 bittiä.
Fyysisillä osoitteilla toimiva TAG on siis myös pienempi kuin virtuaalisilla osoitteilla toimiva olisi.
Ja sen TLB-lookupin L1-TLBstä pystyy tosiaan helposti tekemään rinnakkain way predictionin ja varsinaisten data- ja tag-array-accessien kanssa, joten se ei ainakaan millään tavalla aiheuta yhtään lisää viivettä siihen lataukseen; Päin vastoin, kun tuon kaikkein viimeisenä olevan vertailijan koko putoaa 37 bitistä 30, se potentiaalisesti jopa nopeutuu hiukan.
Intelin Tiger Laken kanssa yleinen suorituskykypudotus akkuvirralla on paljon pienempi. Saa nähdä, että tuleeko myöhemmin jotain ajurisäätöä asiaan liittyen.
