Re: MESI
oznacio sam delove tvoga teksta koji mi nisu jasni crvenom bojom....
posle sam zelenom objasnio sta mi tu ne valja
posalji mi molim te sve sto mislis da bi mi koristilo; moja adresa je zareac@galeb.etf.bg.ac.yu
-----Original Message-----
From: Stojiljkovic Predrag <lordps@tesla.rcub.bg.ac.yu>
To: mips-nastava@titan.etf.bg.ac.yu <mips-nastava@titan.etf.bg.ac.yu>
Date: Friday, February 21, 2003 2:00 PM
Subject: Re: [mips-nastava] MESI
Sto se tice ispitnog zadatka, gde je trebala da se popuni tabela, meni i dalje ostaje misterija vezana za signale INV = 0 i INV = 1.
Al' opet, evo mog vidjenja, koje bi trebalo da otvori raspravu... cache krene u snooping iliti njuskanje.... i vidi da postoje u drugim cachevima podaci koji bi trebali da budu kao taj njegov.
Ako mu je direktiva INV=1 on te podatke u drugim cachevima ne azurira, vec ih proglasi ne vazecim.
Ako mu je direktiva INV =0 , on krece u azuriranje ostalih cacheva i sada podatak postaje Shared jer svi imaju istu kopiju.
Zare
Sto se tice ovog njuskanja, ja sam ga razumeo na sledeci nacin:
Svi kontroleri keseva svih procesora konstantno njuskaju po magistralama. Kad neki kontroler nanjusi da je neki drugi procesor cackao neki podatak, onda ovaj kontroler proverava u kom je stanju taj podak u svome kesu. Ukoliko je taj podatak prisutan u njegovom kesu, onda treba da mu promeni stanje. U koje ce stanje sada ta linija da predje zavisi od toga sta je onaj procesor koji je cackao podatak zapravo radio sa tim podatkom. Procesor koji cacka podatak bi trebalo da generise signal INV (to je kako sam ja razumeo kontrolni signal). I sada, ako je taj procesor menjao taj podatak, onda treba da posalje signal INV=1, sto treba da oznaci svim ostalim procesorima u sistemu (koji njuskaju) da je taj podatak menjan i da treba da ga u svom kesu oznace kao nevalidnog. Ukoliko je procesor samo citao podatak, onda salje signal INV=0 sto oznacava ostalim procesorima da je podatak u njihovim kesevima i dalje validan. ( kada procesor cita podatak nema smisla da generise bilo kakav signal, sto bi uopste bilo sta generisao i bilo koga upozoravao na bilo sta, kada se nista nije desilo sa podatkom??? )
Procesori koji njuskaju treba da promene stanje linije koja je cackana (ovde treba biti precizan: dakle samo za onu liniju koja je izmenjena, treba javiti DRUGIM kesevima sta s njom da rade) u svome kesu na sledeci nacin:
INV=0:
- Ako je linija u stanju M, (znaci da je validan podatak prisutan samo u tom kesu a ne i u memoriji) onda se od ovog kesa zahteva da uradi write-back tj. da prepise podatak u memoriju kako bi onaj procesor koji zahteva taj podatak dobio validnu kopiju podatka. S obzirom da ce se sada ovaj podatak naci u dva kesa, stanje se menja u Shared (...i to u oba kesa).
-Ako je linija u stanju E (ni u jednom vise kesu se nije nalazio ovaj podatak), treba da promeni stanje u S jer ce se sada podatak nalaziti u jos jednom kesu (onog procesora koji taj podatak cita).
-Ako je linija u stanju S (podatak se nalazio u vise keseva), ostaje u istom stanju (S) jer ce sada podatak biti samo u jos jednom kesu vise (i dalje ga ima u vise keseva)
-Ako je linija u stanju I (podatak se ne nalazi u tom kesu), i dalje ostaje u tom stanju (tog kesa se taj podatak ne tice).
INV=1:
U ovom slucaju ce sve odgovarajuce linije u svim kesevima preci u stanje I bez obzira u kom su se stanju ranije nalazile, jer im je ovim signalom receno da podatak u njihovim kesevima vise nije validan (procesor koji je cackao taj podatak ga je usput i promenio). Jedino sto je potrebno (kao i u slucaju INV=0) jeste ako se ta linija u nekom kesu nalazila u stanju M, da se izvrsi prvo write-back (u ovo nisam 100% siguran, ali mislim da je tako).
E sad, ono sto mene buni jeste sledece:
1) Ovo sve deluje OK kada je u pitanju write-back politika upisa u memoriju i write-invalidate protokol. Sta se desava kada je u pitanju write-update protokol (kada se vrsi update-ovanje keseva koji njuskaju po magistralama i na koji nacin)? (ja opet mislim da INV=0 i INV=1 upravo znace Write Update, odnosno Write Invalidate, zar ne??? , jer se termini Write Update i Write Invalidate upravo odnose na to sta se radi sa izmenjenim podacima u samim kesevima) (Za write-through politiku upisa u memoriju sam shvatio da ne podrzava u potpunosti MESI jer stanje M gubi smisao.)
2) Da li bitovi WB/WT i PWT imaju ikakve veze sa tim da li je u pitanju write-update ili write-invalidate protokol, i ako imaju kako, a ako nemaju, sta oni onda konkretno oznacavaju.
Pedja
P.S. Hvala ti Zare na odgovoru, pomogao mi je da povezem neke stvari, ali bih imao par ispravki vezanih za tvoj odgovor. Ako te zanimaju, javi se pa cu ti ih poslati (da ne bih sada duzio ovo pismo, ionako je predugo)
P.P.S. Gvozdene, molim te ukljuci se malo i ti. Ovo nije bas najsrecnije objasnjeno u knjizi. Kao jedino objasnjenje (pogotovo za PWT i WB/WT) su date table iz kojih bi mi trebalo da shvatimo citavu sustinu MESI protokola, ali bih ja to objasnjenje prokomentarisao kao blago receno "sturo". (Taman kad pomislim da sam nesto shvatio, nesto drugo me potpuno zbuni)
posle sam zelenom objasnio sta mi tu ne valja
posalji mi molim te sve sto mislis da bi mi koristilo; moja adresa je zareac@galeb.etf.bg.ac.yu
-----Original Message-----
From: Stojiljkovic Predrag <lordps@tesla.rcub.bg.ac.yu>
To: mips-nastava@titan.etf.bg.ac.yu <mips-nastava@titan.etf.bg.ac.yu>
Date: Friday, February 21, 2003 2:00 PM
Subject: Re: [mips-nastava] MESI
Sto se tice ispitnog zadatka, gde je trebala da se popuni tabela, meni i dalje ostaje misterija vezana za signale INV = 0 i INV = 1.
Al' opet, evo mog vidjenja, koje bi trebalo da otvori raspravu... cache krene u snooping iliti njuskanje.... i vidi da postoje u drugim cachevima podaci koji bi trebali da budu kao taj njegov.
Ako mu je direktiva INV=1 on te podatke u drugim cachevima ne azurira, vec ih proglasi ne vazecim.
Ako mu je direktiva INV =0 , on krece u azuriranje ostalih cacheva i sada podatak postaje Shared jer svi imaju istu kopiju.
Zare
Sto se tice ovog njuskanja, ja sam ga razumeo na sledeci nacin:
Svi kontroleri keseva svih procesora konstantno njuskaju po magistralama. Kad neki kontroler nanjusi da je neki drugi procesor cackao neki podatak, onda ovaj kontroler proverava u kom je stanju taj podak u svome kesu. Ukoliko je taj podatak prisutan u njegovom kesu, onda treba da mu promeni stanje. U koje ce stanje sada ta linija da predje zavisi od toga sta je onaj procesor koji je cackao podatak zapravo radio sa tim podatkom. Procesor koji cacka podatak bi trebalo da generise signal INV (to je kako sam ja razumeo kontrolni signal). I sada, ako je taj procesor menjao taj podatak, onda treba da posalje signal INV=1, sto treba da oznaci svim ostalim procesorima u sistemu (koji njuskaju) da je taj podatak menjan i da treba da ga u svom kesu oznace kao nevalidnog. Ukoliko je procesor samo citao podatak, onda salje signal INV=0 sto oznacava ostalim procesorima da je podatak u njihovim kesevima i dalje validan. ( kada procesor cita podatak nema smisla da generise bilo kakav signal, sto bi uopste bilo sta generisao i bilo koga upozoravao na bilo sta, kada se nista nije desilo sa podatkom??? )
Procesori koji njuskaju treba da promene stanje linije koja je cackana (ovde treba biti precizan: dakle samo za onu liniju koja je izmenjena, treba javiti DRUGIM kesevima sta s njom da rade) u svome kesu na sledeci nacin:
INV=0:
- Ako je linija u stanju M, (znaci da je validan podatak prisutan samo u tom kesu a ne i u memoriji) onda se od ovog kesa zahteva da uradi write-back tj. da prepise podatak u memoriju kako bi onaj procesor koji zahteva taj podatak dobio validnu kopiju podatka. S obzirom da ce se sada ovaj podatak naci u dva kesa, stanje se menja u Shared (...i to u oba kesa).
-Ako je linija u stanju E (ni u jednom vise kesu se nije nalazio ovaj podatak), treba da promeni stanje u S jer ce se sada podatak nalaziti u jos jednom kesu (onog procesora koji taj podatak cita).
-Ako je linija u stanju S (podatak se nalazio u vise keseva), ostaje u istom stanju (S) jer ce sada podatak biti samo u jos jednom kesu vise (i dalje ga ima u vise keseva)
-Ako je linija u stanju I (podatak se ne nalazi u tom kesu), i dalje ostaje u tom stanju (tog kesa se taj podatak ne tice).
INV=1:
U ovom slucaju ce sve odgovarajuce linije u svim kesevima preci u stanje I bez obzira u kom su se stanju ranije nalazile, jer im je ovim signalom receno da podatak u njihovim kesevima vise nije validan (procesor koji je cackao taj podatak ga je usput i promenio). Jedino sto je potrebno (kao i u slucaju INV=0) jeste ako se ta linija u nekom kesu nalazila u stanju M, da se izvrsi prvo write-back (u ovo nisam 100% siguran, ali mislim da je tako).
E sad, ono sto mene buni jeste sledece:
1) Ovo sve deluje OK kada je u pitanju write-back politika upisa u memoriju i write-invalidate protokol. Sta se desava kada je u pitanju write-update protokol (kada se vrsi update-ovanje keseva koji njuskaju po magistralama i na koji nacin)? (ja opet mislim da INV=0 i INV=1 upravo znace Write Update, odnosno Write Invalidate, zar ne??? , jer se termini Write Update i Write Invalidate upravo odnose na to sta se radi sa izmenjenim podacima u samim kesevima) (Za write-through politiku upisa u memoriju sam shvatio da ne podrzava u potpunosti MESI jer stanje M gubi smisao.)
2) Da li bitovi WB/WT i PWT imaju ikakve veze sa tim da li je u pitanju write-update ili write-invalidate protokol, i ako imaju kako, a ako nemaju, sta oni onda konkretno oznacavaju.
Pedja
P.S. Hvala ti Zare na odgovoru, pomogao mi je da povezem neke stvari, ali bih imao par ispravki vezanih za tvoj odgovor. Ako te zanimaju, javi se pa cu ti ih poslati (da ne bih sada duzio ovo pismo, ionako je predugo)
P.P.S. Gvozdene, molim te ukljuci se malo i ti. Ovo nije bas najsrecnije objasnjeno u knjizi. Kao jedino objasnjenje (pogotovo za PWT i WB/WT) su date table iz kojih bi mi trebalo da shvatimo citavu sustinu MESI protokola, ali bih ja to objasnjenje prokomentarisao kao blago receno "sturo". (Taman kad pomislim da sam nesto shvatio, nesto drugo me potpuno zbuni)
- Follow-Ups:
- Re: MESI
- From: "Gvozden Marinkovic" <mgvozden@eunet.yu>
- Re: MESI