Mam takie pytanie z lekka akademickie.

Mamy architekturę x86. Dowolnego producenta, z gatunku bardziej
współczesnych.

Każdy rdzeń ma osobne cache L1.

Wyobraźmy sobie że mamy procesor caly dla siebie. Nie ma systemu
operacyjnego.

Uruchamiam dwa cory. W pamięci znajduje się jeden int. Pierwszy core
czeka chwile i ustawia wartość tego inta na 1 po czym wpada w ciasną
pętlę bez wyjścia.

Drugi core sprawdza w ciasnej pętli wartość tej komórki pamięci i jak
jest "1" to coś robi.

Pytanie: jeśli nie zastosuje żadnych barier pamięci, to czy cache core2
po jakimś czasie zostanie zaktualizowane zazwartością cache core1? Jest
to mętnie opisane i zazwyczaj w kontekscie barier pamięci. Mnie
natomiast interesuje czy procesor sam z siebie dokonuje synchronizacji
cache L1. Zakładam że nie, ale to jest x86 i wiele pewno zrobiono dla
kompatyblinosci z kiepskim softem :/

PS. Mniej więcej podobny problem istnieje w prawdziwym sofcie - flaga
zmienia stan miliony cykli później niż jej ustawienie. Kod nie posiada
barier pamięci - a mnie interesuje kto ją "zsynchronizował"- czy OS czy
się samo zrobiło.

do góry

On Tuesday, May 19, 2015 at 7:31:38 PM UTC+2, Sebastian Biały wrote:
> Pytanie: jeśli nie zastosuje żadnych barier pamięci, to czy cache core2
> po jakimś czasie zostanie zaktualizowane zazwartością cache core1? Jest
> to mętnie opisane i zazwyczaj w kontekscie barier pamięci. Mnie
> natomiast interesuje czy procesor sam z siebie dokonuje synchronizacji
> cache L1. Zakładam że nie, ale to jest x86 i wiele pewno zrobiono dla
> kompatyblinosci z kiepskim softem :/

Jest synchronizacja, to się nazywa snooping: "When operating in an MP system,
[...] processors have the ability to snoop other processor's accesses to system
memory and to their internal caches. They use this snooping ability to keep
their internal caches consistent both with system memory and with the caches
in other processors on the bus" (za System Programming Guide).

w.

do góry

On 2015-06-09 08:22, Wojciech Muła wrote:
> Jest synchronizacja, to się nazywa snooping

Wiem, czytalem ogromną ilość opisów jak działają protokoły spójności
cache i problem jest mocno zawiły. W żadnym nie natrafiłem na informacje
po jakim *czasie* L1 są synchronizowane albo np. po jakim czasie zapis
pamięci w CPU0 widoczny jest w CPU1. Wszyscy mowią o memory ordering ale
nikt nie mówi jak szybo widać zmiany :). Albo jest to czas pomijalnie
mały albo czytałem złe dokumenty.

do góry

On Tuesday, June 9, 2015 at 6:19:38 PM UTC+2, Sebastian Biały wrote:
> On 2015-06-09 08:22, Wojciech Muła wrote:
> > Jest synchronizacja, to się nazywa snooping
>
> Wiem, czytalem ogromną ilość opisów jak działają protokoły spójności
> cache i problem jest mocno zawiły. W żadnym nie natrafiłem na informacje
> po jakim *czasie* L1 są synchronizowane albo np. po jakim czasie zapis
> pamięci w CPU0 widoczny jest w CPU1. Wszyscy mowią o memory ordering ale
> nikt nie mówi jak szybo widać zmiany :). Albo jest to czas pomijalnie
> mały albo czytałem złe dokumenty.

Snooping działa w chwili odczytu, więc można przyjąć że pomijalnie. Na x86
domyślnie nie masz problemu z orderingiem, bo wszystkie dostępy są
serializowane (wyjątkiem są operacje SSE).

Ale faktycznie, ciekawie to by było na PowerPC gdzie wszystkie dostępy są
weak-ordered. Muszę doczytać. :)

w.

do góry

On Wed, 10 Jun 2015 01:24:44 -0700 (PDT), Wojciech
Muła<w...@g...com> wrote:
> Snooping działa w chwili odczytu, więc można przyjąć że pomijal=
> nie.

Co to znaczy pomijalnie? Rzędu nanosekund?

RW

do góry

On 2015-06-10 10:24, Wojciech Muła wrote:
> Na x86
> domyślnie nie masz problemu z orderingiem, bo wszystkie dostępy są
> serializowane (wyjątkiem są operacje SSE).

Nie wszystkie. Np. load przeplata się ze store jesli dotyczą róznych
komorek pamięci. x86 też ma pułapki.

http://preshing.com/20120515/memory-reordering-caugh
t-in-the-act/

http://stackoverflow.com/questions/20907811/x86-memo
ry-ordering-loads-reordered-with-earlier-stores-vs-i
ntra-processor-for

Najbardziej zabawne że pytanie które zadalem wyszło wlaśnie z takiego
przypadku pod lupą - pewne flagi ustawiane na cpux miały niedozwolony
stan na cpuy. Podczas analizy okazało się dodatkowo że flagi te
propagowały się do sąsiednich rdzeni zaskakująco długo i nie potrafie
tego wyjasnić.

do góry