Re: MESI
Molio bih Gvozdena da ima strpljenja, i iako su ova pisma duga da ih detaljno procita i ispravi me ako gresim (ili me makar obavesti da gresim, da ne lupam gluposti a da nisam toga svestan). Takodje bih ga molio da mi objasni ono sto meni i dalje nije jasno, tj. (znam da sam dosadan, ali sam i radoznao) o cemu se radi sa tim WB/WT i PWT bitima.
U nastavku slede neka objasnjenja vezana za MESI, makar onako kako sam ja to razumeo.
1) Znacenje WB/WT pina (malo detaljnije nego Writeback/Writethrough, tipa ko generise kontrolni signal za ovaj pin i cemu on konkretno sluzi)
Zare: postoje cetiri situacije, koje tebi nisu jasne:
1. prilikom citanja podatak iz Invalid prelazi u Exclusive (WB/WT# =1)
2. prilikom citanja iz Invalid prelazi u Shared (WB/WT# = 0)
U slucaju prve situacije, podatak u cache-u je isti kao u glavnoj memoriji, ali je moguce da podatak nije toliko bitan pa se 'ne organizuje' azuriranje ostalih cacheva u sistemu.
U slucaju druge situacije, ostali cachevi nisu IDLE, vec i oni svoje podatke azuriraju, sa kopijom koja se pojavljuje na magistrali, kada je onaj koji hoce da je procita dovlaci iz glavne memorije.
Kao sto sam objasnio u tacki pod 2) postoje podaci za koje ima smisla ovakav scenario.
3. prilikom upisa podatak iz Shared ide u Exclusive... pa slicna prica kao gore... podatak nije 'od presudnog znacaja za sistem' , pa se ne organizuje azuriranje ostalih cacheva
4. Shared to Shared... ovde to jeste
Ovde nije bitno da li je podatak 'bitan' ili 'nebitan'. Radi se o sledecem:
Kada procesor hoce da procita neki podatak, a taj podatak se ne nalazi u njegovom kesu (tj. ta linija je u njegovom kesu u stanju I), on treba da nekako provali da li se taj podatak nalazi u drugim kesevima ili ne. (mislim da je to na neki nacin odredjeno bitovima WB/WT i PWT, ali kako MENI NIJE JASNO, A NIKO NECE DA MI OBJASNI). Sada, ako provali da se taj podatak ne nalazi u drugim kesevima, onda ce ga on dovuci u svoj kes iz memorije, i tako ce ga samo on posedovati u svom kesu, pa ta linija u njegovom kesu treba da predje iz stanja I u stanje E. Ukoliko provali da se taj podatak nalazi i u nekom drugom (drugim) kesu (kesevima), onda ta linija u njegovom kesu treba da predje iz stanja I u stanje S (jer nije jedini koji poseduje taj podatak u svom kesu). Podatak moze da ne bude predvidjen za kesiranje, pa onda nece biti dovucen u kes, pa ta linija u kesu ostaje u stanju Invalid (tj. nema tog podatka u kesu).
Kod upisa, kada se linija nalazi u stanju S, ponovo ce svoje prste umesati bitovi PWT i WB/WT (na meni misteriozan nacin). Ali sustina je sledeca:
Ukoliko se radi o write-invalidate protokolu, procesor ce promeniti podatak u svom kesu, i ostale procesore obavestiti (sa INV=1) da tu liniju u svom kesu oznace kao Invalid. Tako ce on biti jedini koji ce drzati validan podatak u svom kesu, pa ce iz stanja S preci u stanje E (dok ce svi ostali, koji su drzali taj podatak, tu liniju prebaciti iz stanja S u stanje stanje I). Mislim da si ovde u pravu (tacka 3. mog pisma), tj. da se podatak kada se prvi put menja zapisuje i u memoriju, pa se zbog toga ne prelazi iz stanja S u stanje M (u ovom slucaju).
Ukoliko se radi o write-update protokolu, procesor ce promeniti podatak u svom kesu, ali ce i svim ostalim procesorima koji drze taj isti podatak signalizirati (ponovo sa INV=1) da je taj podatak menjan, i da i oni treba da ga azuriraju u svojim kesevima. Tu ce sada zapoceti onaj write-through ciklus na magistrali, gde ce se obaviti azuriranje podataka u ostalim kesevima. Posle ovog ciklusa, svi kesevi (koji su ranije drzali ovaj podatak) ce i dalje u sebi imati VALIDAN podatak. Na taj nacin i onaj kes koji je menjao podatak, kao i svi ostali kesevi koji su drzali (i dalje drze) taj podatak, treba da zadrze stanje te linije tj. stanje S (podatak se nalazi u vise keseva). E sada, ovde ne mora da bude azurirana glavna memorija (ukoliko se radi o write-back politici upisa), ali moze (ukoliko se radi o write-through politici upisa). Makar tako pise u profesorovoj knjizi, a i poprilicno je logicno.
2) Tranziciju I -> S prilikom citanja
ovo je i meni misterija, ali sasvim je moguce da zbog toga sto je aktivan WT# signal (jer je tada WB/WT# = 0) , ostali cachevi nisu IDLE vec grabe svezu kopiju, u isto vreme kad i onaj koji je stvarno trazio taj podatak radi citanja. Moguce je cak i da se sistemski neki podaci oznace kao takvi da kada jedan cache zapocne njihovo citanje i dovlacenje iz glavne memorije, da i ostali cachevi krenu da azuriraju svoje kopije, iako im u tom trenutku ti podaci nisu potrebni
Mislim da si ovo totalno promasio, ali mi je tvoj odgovor pomogao da ja shvatim ono sto mi u trenutku kada sam pisao ovo pismo nije bilo jasno. Ovde oni kesevi koji drze u sebi taj podatak nece dograbiti svezu kopiju, jer ako je ta linija kod njih u stanju S (eventualno E, ako samo jedan procesor u tom trenutku ima taj podatak u kesu), to vec podrazumeva da je taj podatak kod njih azuran (validan). Ostatak koji se tice ove tranzicije sam vec objasnjavao (vidi gore).
3) Zasto ne moze iz stanja S da se predje u stanje M prilikom pisanja?
Takvo je pravilo... prilikom prvog upisa, azurira se glavna memorija, a statistika je pokazala da ako dodje do drugog upisa nema svrhe azurirati ponovo glavnu memoriju, jer ce doci i do treceg, cetvrtog... pa se stoga podatak proglasava Modified
Ovo mislim da si potpuno u pravu (makar sto se tice write-invalidate protokola). Deluje mi sasvim logicno, a i to objasnjava tabelu u profesorovoj knjizi. Jedino mislim da se kod write-update protokola sa write-back politikom upisa ne mora prvi put (a ni "sledecih puta") azurirati memorija (ali se azuriraju svi ostali kesevi koji drze taj podatak), ali u ovo nisam u potpunosti siguran.
Pedja
P.S. Nadam se, Zare, da si zadovoljan odgovorom.
P.P.S. Gvozdene, javi se.
U nastavku slede neka objasnjenja vezana za MESI, makar onako kako sam ja to razumeo.
1) Znacenje WB/WT pina (malo detaljnije nego Writeback/Writethrough, tipa ko generise kontrolni signal za ovaj pin i cemu on konkretno sluzi)
Zare: postoje cetiri situacije, koje tebi nisu jasne:
1. prilikom citanja podatak iz Invalid prelazi u Exclusive (WB/WT# =1)
2. prilikom citanja iz Invalid prelazi u Shared (WB/WT# = 0)
U slucaju prve situacije, podatak u cache-u je isti kao u glavnoj memoriji, ali je moguce da podatak nije toliko bitan pa se 'ne organizuje' azuriranje ostalih cacheva u sistemu.
U slucaju druge situacije, ostali cachevi nisu IDLE, vec i oni svoje podatke azuriraju, sa kopijom koja se pojavljuje na magistrali, kada je onaj koji hoce da je procita dovlaci iz glavne memorije.
Kao sto sam objasnio u tacki pod 2) postoje podaci za koje ima smisla ovakav scenario.
3. prilikom upisa podatak iz Shared ide u Exclusive... pa slicna prica kao gore... podatak nije 'od presudnog znacaja za sistem' , pa se ne organizuje azuriranje ostalih cacheva
4. Shared to Shared... ovde to jeste
Ovde nije bitno da li je podatak 'bitan' ili 'nebitan'. Radi se o sledecem:
Kada procesor hoce da procita neki podatak, a taj podatak se ne nalazi u njegovom kesu (tj. ta linija je u njegovom kesu u stanju I), on treba da nekako provali da li se taj podatak nalazi u drugim kesevima ili ne. (mislim da je to na neki nacin odredjeno bitovima WB/WT i PWT, ali kako MENI NIJE JASNO, A NIKO NECE DA MI OBJASNI). Sada, ako provali da se taj podatak ne nalazi u drugim kesevima, onda ce ga on dovuci u svoj kes iz memorije, i tako ce ga samo on posedovati u svom kesu, pa ta linija u njegovom kesu treba da predje iz stanja I u stanje E. Ukoliko provali da se taj podatak nalazi i u nekom drugom (drugim) kesu (kesevima), onda ta linija u njegovom kesu treba da predje iz stanja I u stanje S (jer nije jedini koji poseduje taj podatak u svom kesu). Podatak moze da ne bude predvidjen za kesiranje, pa onda nece biti dovucen u kes, pa ta linija u kesu ostaje u stanju Invalid (tj. nema tog podatka u kesu).
Kod upisa, kada se linija nalazi u stanju S, ponovo ce svoje prste umesati bitovi PWT i WB/WT (na meni misteriozan nacin). Ali sustina je sledeca:
Ukoliko se radi o write-invalidate protokolu, procesor ce promeniti podatak u svom kesu, i ostale procesore obavestiti (sa INV=1) da tu liniju u svom kesu oznace kao Invalid. Tako ce on biti jedini koji ce drzati validan podatak u svom kesu, pa ce iz stanja S preci u stanje E (dok ce svi ostali, koji su drzali taj podatak, tu liniju prebaciti iz stanja S u stanje stanje I). Mislim da si ovde u pravu (tacka 3. mog pisma), tj. da se podatak kada se prvi put menja zapisuje i u memoriju, pa se zbog toga ne prelazi iz stanja S u stanje M (u ovom slucaju).
Ukoliko se radi o write-update protokolu, procesor ce promeniti podatak u svom kesu, ali ce i svim ostalim procesorima koji drze taj isti podatak signalizirati (ponovo sa INV=1) da je taj podatak menjan, i da i oni treba da ga azuriraju u svojim kesevima. Tu ce sada zapoceti onaj write-through ciklus na magistrali, gde ce se obaviti azuriranje podataka u ostalim kesevima. Posle ovog ciklusa, svi kesevi (koji su ranije drzali ovaj podatak) ce i dalje u sebi imati VALIDAN podatak. Na taj nacin i onaj kes koji je menjao podatak, kao i svi ostali kesevi koji su drzali (i dalje drze) taj podatak, treba da zadrze stanje te linije tj. stanje S (podatak se nalazi u vise keseva). E sada, ovde ne mora da bude azurirana glavna memorija (ukoliko se radi o write-back politici upisa), ali moze (ukoliko se radi o write-through politici upisa). Makar tako pise u profesorovoj knjizi, a i poprilicno je logicno.
2) Tranziciju I -> S prilikom citanja
ovo je i meni misterija, ali sasvim je moguce da zbog toga sto je aktivan WT# signal (jer je tada WB/WT# = 0) , ostali cachevi nisu IDLE vec grabe svezu kopiju, u isto vreme kad i onaj koji je stvarno trazio taj podatak radi citanja. Moguce je cak i da se sistemski neki podaci oznace kao takvi da kada jedan cache zapocne njihovo citanje i dovlacenje iz glavne memorije, da i ostali cachevi krenu da azuriraju svoje kopije, iako im u tom trenutku ti podaci nisu potrebni
Mislim da si ovo totalno promasio, ali mi je tvoj odgovor pomogao da ja shvatim ono sto mi u trenutku kada sam pisao ovo pismo nije bilo jasno. Ovde oni kesevi koji drze u sebi taj podatak nece dograbiti svezu kopiju, jer ako je ta linija kod njih u stanju S (eventualno E, ako samo jedan procesor u tom trenutku ima taj podatak u kesu), to vec podrazumeva da je taj podatak kod njih azuran (validan). Ostatak koji se tice ove tranzicije sam vec objasnjavao (vidi gore).
3) Zasto ne moze iz stanja S da se predje u stanje M prilikom pisanja?
Takvo je pravilo... prilikom prvog upisa, azurira se glavna memorija, a statistika je pokazala da ako dodje do drugog upisa nema svrhe azurirati ponovo glavnu memoriju, jer ce doci i do treceg, cetvrtog... pa se stoga podatak proglasava Modified
Ovo mislim da si potpuno u pravu (makar sto se tice write-invalidate protokola). Deluje mi sasvim logicno, a i to objasnjava tabelu u profesorovoj knjizi. Jedino mislim da se kod write-update protokola sa write-back politikom upisa ne mora prvi put (a ni "sledecih puta") azurirati memorija (ali se azuriraju svi ostali kesevi koji drze taj podatak), ali u ovo nisam u potpunosti siguran.
Pedja
P.S. Nadam se, Zare, da si zadovoljan odgovorom.
P.P.S. Gvozdene, javi se.
Previous by date: Re: MESI
Next by date: Re: MESI
Previous by thread: Re: MESI Next by thread: vektor tabela!
Previous by thread: Re: MESI Next by thread: vektor tabela!