Re: MESI
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??? )
Evo objasnjenja:
Zamisli situaciju da je neki procesor u svom kesu imao podatak koji je bio u stanju E. I sada se desi da neki drugi procesor isti taj podatak dovuce u svoj kes (cita podatak iz memorije i samim tim ga dovlaci u svoj kes). Sada taj podatak u kesu prvog procesora ne sme da ostane u stanju E (jer bi to znacilo da se podatak nalazi samo u njegovom kesu), vec mora da predje u stanje S (sto oznacava da se sada taj podatak, tj. ta linija, nalazi u vise od jednog kesa, u ovom slucaju i u kesu onog drugog procesora koji je upravo procitao taj podatak). Zbog toga procesor koji cita podatak treba da obavesti i ostale procesore da je podatak sada i u njegovom kesu (kako bi neko od njih eventualno presao iz stanja E u S, ili iz M u S. U slucaju da je vise procesora imalo taj podatak u svojim kesevima, znaci da je ta linija kod njih bila u stanju S, pa samo treba da i dalje zadrzi to stanje). To obavestenje se salje preko linije INV, kao INV=0, a Gvozden je objasnio kako se to zapravo ostvaruje.
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:
....
Ovde mozes da vidis (iz onog sto sam prethodno objasnjavao) da se ne radi samo o linijama koje su menjane vec i o linijama koje su citane (jer mozda nisu citane direktno iz keseva vec su mozda dovucene iz memorije u kes direktno pre citanja).
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.)
Ovo je vec Gvozden objasnio u drugom mail-u, i ocigledno INV ne odredjuje protokol. Sam INV bit, u slucaju write-update protokola, sa INV=1 signalizira update-ovanje ostalim kesevima u slucaju write-update protokola, a u slucaju write-invalidate protokola INV=1 signalizira ostalim kesevima da taj podatak (cija se adresa u tom trenutku nalazi na adresnoj magistrali, a sam podatak (eventualno) na magistrali podataka) proglasi nevazecim.
Nadam se da ti je ovo razjasnilo malo MESI protokol. Poslacu jos jedno pismo (kao odgovor na tvoj prvi odgovor) na mailing listu, gde cu malo ispraviti ono gde mislim da si pogresio (ono sto mislim da nisi dobro razumeo). Ako imas jos pitanja, slobodan si da mi se obratis, ako mogu pokusacu da ti odgovorim.
Pedja
Evo objasnjenja:
Zamisli situaciju da je neki procesor u svom kesu imao podatak koji je bio u stanju E. I sada se desi da neki drugi procesor isti taj podatak dovuce u svoj kes (cita podatak iz memorije i samim tim ga dovlaci u svoj kes). Sada taj podatak u kesu prvog procesora ne sme da ostane u stanju E (jer bi to znacilo da se podatak nalazi samo u njegovom kesu), vec mora da predje u stanje S (sto oznacava da se sada taj podatak, tj. ta linija, nalazi u vise od jednog kesa, u ovom slucaju i u kesu onog drugog procesora koji je upravo procitao taj podatak). Zbog toga procesor koji cita podatak treba da obavesti i ostale procesore da je podatak sada i u njegovom kesu (kako bi neko od njih eventualno presao iz stanja E u S, ili iz M u S. U slucaju da je vise procesora imalo taj podatak u svojim kesevima, znaci da je ta linija kod njih bila u stanju S, pa samo treba da i dalje zadrzi to stanje). To obavestenje se salje preko linije INV, kao INV=0, a Gvozden je objasnio kako se to zapravo ostvaruje.
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:
....
Ovde mozes da vidis (iz onog sto sam prethodno objasnjavao) da se ne radi samo o linijama koje su menjane vec i o linijama koje su citane (jer mozda nisu citane direktno iz keseva vec su mozda dovucene iz memorije u kes direktno pre citanja).
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.)
Ovo je vec Gvozden objasnio u drugom mail-u, i ocigledno INV ne odredjuje protokol. Sam INV bit, u slucaju write-update protokola, sa INV=1 signalizira update-ovanje ostalim kesevima u slucaju write-update protokola, a u slucaju write-invalidate protokola INV=1 signalizira ostalim kesevima da taj podatak (cija se adresa u tom trenutku nalazi na adresnoj magistrali, a sam podatak (eventualno) na magistrali podataka) proglasi nevazecim.
Nadam se da ti je ovo razjasnilo malo MESI protokol. Poslacu jos jedno pismo (kao odgovor na tvoj prvi odgovor) na mailing listu, gde cu malo ispraviti ono gde mislim da si pogresio (ono sto mislim da nisi dobro razumeo). Ako imas jos pitanja, slobodan si da mi se obratis, ako mogu pokusacu da ti odgovorim.
Pedja
Previous by date: Re: dve ptalice
Next by date: Re: MESI
Previous by thread: Re[2]: MESI Next by thread: Re: MESI
Previous by thread: Re[2]: MESI Next by thread: Re: MESI