Chapter 03. 하드웨어와 운영체제

[MinJunKweon]

느낀점

• MESI 프로토콜, Branch Prediction, ... 대학생 때 컴퓨터구조가 생각나는 챕터
• 그만큼 한장 한장 넘기기가 어렵다

정리

• 무어의 법칙에 따라 트랜지스터 수가 급증함
• 트랜지스터 수가 급증하면서 클락 속도(Clock speed)를 높이는 데에 쓰임
  • 그 이유는 초당 많은 명령어를 처리하기 위해서
• 프로세서가 점점 빨라지면서 처리하는 명령어가 많아질수록 데이터도 빨리 움직여야하는 문제 발생
• 시간이 갈수록 프로세서 코어에서 요청하는 데이터를 메인 메모리가 맞춰주기 어려워짐
  • 무어의 법칙에 따르면 프로세서 성능이 매해 60%씩 증가함
  • 반면, DRAM의 성능은 매해 7%씩 증가함
  • 따라서, 해가 지날수록 프로세서와 메모리 성능 간극은 50%씩 증가함
• 이 간극을 해결하기 위해 CPU 캐시가 등장
• CPU 캐시는 메모리에서 인출한 데이터를 CPU쪽 SRAM에 저장함
• CPU 캐시는 접근하는 빈도가 높은 캐시일수록 프로세서 코어에 가까이 위치하도록 레벨을 나눔
  • CPU에 가장 가까운 캐시 L1 캐시, 그다음 L2 캐시 (코어 전용인 프라이빗 캐시)
  • 모든 코어가 공유하는 L3 캐시
• 캐시와 메인 메모리 간의 상태를 보장하는 캐시 일관성 프로토콜(Cache Consistency Protocol)을 사용함
  • 일관성 프로토콜은 MESI 프로토콜이 자주 사용됨

MESI 프로토콜

• Modified : 데이터가 수정된 상태
• Exclusive : 이 캐시에만 존재하고 메인 메모리 내용과 동일한 상태
• Shared : 둘 이상의 캐시에 데이터가 들어있고 메모리 내용과 동일한 상태
• Invalid : 다른 프로세스가 데이터를 수정하여 무효한 상태

캐시 기록 방식

• Write-through : 캐시 저장과 동시에 메모리에 쓰기
• Write-back : 캐시블록이 더티인 것만 메모리에 기록

변환 색인 버퍼(TLB)

Virtual Memory 주소를 실제 Physical Memory 주소로 변환하기 위해 사용되는 룩업 테이블 캐시

운영체제

• OS별 스케줄링 구현방식에 따라 성능이 천차만별이다
• OS 혹은 머신마다 시간을 측정하는 방식이 다르다. 구현체도 다름
• 컨텍스트 스위칭 방식도 OS별로 세세하게 다름. 그래서 시스템 콜을 쓸 때 영향도가 다르다.

애플리케이션이 제대로 동작하는지 확인하는 전략

• CPU 사용률 측정 (vmstat, iostat 등)
• 가비지 컬렉션 로그를 확인
• 애플리케이션에서 I/O가 얼마나 일어나는지 파악

I/O 성능을 향상시키는 방법 - 커널 바이패스

• 유저레벨의 데이터를 커널레벨로 복사한 뒤 전송하는 방식은 ‘이중 복사’ 문제를 일으켜서 비효율적임
• 따라서, 커널 레벨의 특정 공간을 유저 레벨에서 사용할 수 있도록 하는 방식

더 알아본 것

• 2023년 현재 메모리 대역폭이 대체 얼마나 될까?
  • 이걸 알아보려다 보니.. 아래와 같은 것들을 찾아봐서 정리했음
• DRAM과 SRAM의 차이
  • DRAM : 다이나믹 램. 우리가 생각하는 그 메인 메모리 RAM.
  • SRAM : 스태틱 램. 보통 CPU 캐시에 사용되는 램. DRAM보다 비쌈. 전력도 많이먹음.
• DDR2, DDR3, DDR4가 뭐임?
  • SDRAM(Synchronous DRAM)의 종류임. SDRAM은 시스템 버스와 동기화해서 데이터를 전송하는 DRAM. 시스템 버스를 사용하기 때문에 시스템 클락 신호에 맞춰 데이터를 전송함.
  • DDR은 Double Data Rate의 줄인말. 당연히 Single Data Rate도 있음. 두 개의 차이는 아래와 같음
  • 현재 DDR5까지 있지만 보통 DDR4를 많이 사용하는중. DDR5는 보급이 많이 안된듯
• 그래서 메모리 대역폭은 어떻게 읽음?
  • RAM 벤치마크 표를 보면 Data Rate를 볼 수 있음
  • DDR4-4133은 데이터 전송률이 4133MT/s 라고 읽음. 4133MT/s는 41.33억번 데이터를 전송할 수 있다는 의미
  • DDR4는 메모리를 한번 전송할 때, 8바이트씩 전송할 수 있으므로 1MT/s = 8MB/s 라고 볼 수 있음
  • 따라서, DDR4-4133은 4133*8 = 33,064MB/s의 대역폭을 가짐
    • +) DDR4-4133은 PC4-33064로 표기할 수 있습니다. 같은 말임. (PC는 무엇의 약자인고? 아무뜻 없다고함)
• 결론 : 2023년 기준 최고의 DDR4 램은 초당 33,064MB를 전송할 수 있다

[LOG-INFO]

정리

• 하드웨어의 경이로운 발전으로 인해 Java는 많은 혜택을 보았다
• 하지만 성능을 진지하게 고민하는 Java 프로그래머는 가용 리소스를 최대한 활용할 수 있도록 자바 플랫폼의 근간 원리와 기술을 잘 알고 있어야 한다
• 메모리
  • 무어의 법칙에 따라 개수가 급증한 트랜지스터는 처음엔 클록 속도를 높이는데 쓰였다
  • 하지만 메모리 성능은 그만큼 빠르게 성장하지 못하여 점점 성능차가 발생했다
  • 따라서 CPU 캐시가 고안되어 프로세서 <-> 메모리 사이에서 중재 역할을 해주었다
  • L1 캐시, L2 캐시, L3 캐시, 메인메모리, ...
  • 그 후엔 캐시 일관성 관련 고민을 하게되어 캐시 일관성 프로토콜을 고안하게 됨
  • MESI 프로토콜 (Modified, Exclusive, Shared, Invalid)
  • 캐시 저장 방식
    • Write-through
    • Write-back

    • 오.. 어플리케이션단 캐싱 기법들 공부하다가 들은 단어들이 여기서 먼저 시작된 것 같군

• 최신 프로세서의 특성
  • 변환 색인 버퍼(TLB; Translation Look-aside Buffer): 가상 메모리 주소를 물리 메모리 주소로 매핑하는 페이지 테이블의 캐시 역할
  • 분기 예측(Branch prediction): 가장 발생 가능성이 큰 브랜치를 미리 결정하는 휴리스틱 형성
  • 추측 실행(Speculative Execution): 추측이 맞으면 빠르게 넘어가고, 틀리면 실행한 명령 모두 폐기 후 파이프라인을 비우고 다시 실행
• 운영체제
  • 메모리 관리 유닛(MMU; Memory Management Unit)
  • 메모리 액세스를 제어함으로써, 한 프로세스가 소유한 메모리 영역을 다른 프로세스가 함부로 훼손하지 못하게 함
  • 개발자가 손 대기엔 너무 저수준 영역
  • 프로세스 스케줄러
  • Run queue를 이용해 CPU 액세스를 통제
    • Run queue: 실행 대상이지만 CPU 차례를 기다려야 하는 스레드 혹은 프로세스 대기 장소
  • Unix는 대략 스케줄 10~20%가 오버헤드
  • Windows XP는 180%...?

    • 실제 실행시간보다 기네 ㄷㄷ;

  • Time problem
  • Context Switching
    • OS 스케줄러가 현재 실행중인 스레드/태스크를 없애고 대기 중인 다른 스레드/태스크로 대체하는 프로세스
    • 비싼 작업 (유저-유저 / 유저-커널)
    • 커널 모드로 컨텍스트가 교환되면 TLB를 비롯한 다른 캐시까지도 무효화됨
• 기본 감지 전략
  • vmstat
  • 아 콘솔.... 정렬 깨지는거 그켬....
    • 
  • -w(wide) 옵션 붙이면 그나마 덜 깨짐
    • 

  • swap 섹션은 일단 0을 넘으면 메모리가 부족하다는 뜻이므로 확인해줘야할 듯

    • 토이 플젝에서 EC2 free tier로 실행할 때 일부러 swap 메모리 사용하긴 했었는데.. 실사용하는 예시는 거의 없을 듯. 너무 느려서

  • cpu section
    • us(user)
    • sy(system)
    • id(idle)
    • wa(wait)
    • st(steal): 가상 머신에 할애된 시간
  • iostat
  • 이건 그나마 정렬이 안 깨짐
  • 근데 매번 포맷이 나와서 시간별 비교하기가 불편함
  • 
• Garbage Collection
  • JVM은 메모리를 유저 공간(시스템 공간이 아닌)에 할당/관리
  • 그래서 메모리를 할당하느라 시스템 콜을 할 필요가 없음
  • 유저 공간의 CPU 사이클을 소비하며, 커널 공간의 사용률에 영향을 미치지 않음
  • 즉, 커널 공간 CPU 사용률이 아주 높게 나타날 때 GC는 주범이 아님
  • 단, 유저 공간 CPU 사용률이 아주 높다면 GC를 의심해야 함
  • 이 땐 GC log를 보자 (GC Log는 JVM Option을 수정해서 꼭 남겨야 함. 시스템 리소스 거의 영향 없음)
  • ex)

    2023-03-05T04:16:59.173+0900: 114143.907: [GC pause (G1 Evacuation Pause) (young), 0.1123883 secs]
    [Parallel Time: 94.8 ms, GC Workers: 4]
    [GC Worker Start (ms): Min: 114143912.3, Avg: 114143912.3, Max: 114143912.4, Diff: 0.0]
    [Ext Root Scanning (ms): Min: 7.3, Avg: 7.5, Max: 7.8, Diff: 0.5, Sum: 30.0]
    [Update RS (ms): Min: 17.8, Avg: 18.1, Max: 18.3, Diff: 0.5, Sum: 72.3]
     [Processed Buffers: Min: 780, Avg: 932.2, Max: 1068, Diff: 288, Sum: 3729]
    [Scan RS (ms): Min: 27.6, Avg: 27.8, Max: 28.1, Diff: 0.5, Sum: 111.3]
    [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
    [Object Copy (ms): Min: 41.0, Avg: 41.2, Max: 41.3, Diff: 0.4, Sum: 164.8]
    [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
     [Termination Attempts: Min: 1, Avg: 24.5, Max: 37, Diff: 36, Sum: 98]
    [GC Worker Other (ms): Min: 0.1, Avg: 0.1, Max: 0.2, Diff: 0.1, Sum: 0.5]
    [GC Worker Total (ms): Min: 94.7, Avg: 94.7, Max: 94.8, Diff: 0.1, Sum: 378.9]
    [GC Worker End (ms): Min: 114144007.1, Avg: 114144007.1, Max: 114144007.1, Diff: 0.0]
    [Code Root Fixup: 0.0 ms]
    [Code Root Purge: 0.0 ms]
    [Clear CT: 0.5 ms]
    [Other: 17.0 ms]
    [Choose CSet: 0.0 ms]
    [Ref Proc: 6.5 ms]
    [Ref Enq: 0.9 ms]
    [Redirty Cards: 0.3 ms]
    [Humongous Register: 0.1 ms]
    [Humongous Reclaim: 0.0 ms]
    [Free CSet: 1.6 ms]
    [Eden: 3264.0M(3264.0M)->0.0B(4472.0M) Survivors: 24576.0K->24576.0K Heap: 5550.6M(8192.0M)->2286.8M(8192.0M)]
    [Times: user=0.42 sys=0.00, real=0.12 secs]

궁금한 내용

• p73. JVM의 TLB?
  • 다 Translation Look-aside Buffer 밖에 안나오는데...
• p73. 추측 실행은 불명예스럽게도 2018년 초반 아주 많은 CPU에 영향을 끼친 주요 보안 문제의 근원입니다?
• p79. 명령어와 다른 캐시를 어쩔 수 없이 강제로 비워야 합니다
• p83. cpu section의 wa, st 지표가 언제 발생하는지 궁금함
• p84. `튜닝이 잘 된 프로그램은 리소스(특히, CPU)를 최대한 활용합니다
  • 보통 어플리케이션 서버는 CPU 20~30% 이하로 쓰지 않나? (피크타임을 위해)
  • 다른 분들은 어떻게 사용하시는지 궁금
• p84. sbrk()
  • brk, sbrk: 데이터 세그멘트 크기를 변경하는 리눅스 명령어
  • brk() 와 sbrk()는 program break의 위치를 변경한다. ( program break는 프로세스의 데이터 세그먼트의 끝을 규정한다. 즉, program break은 초기화되지않은 데이터 세그먼트 영역 후의 첫부분의 위치다. )
  • program break를 증가시키는 것은 프로세스에 메모리를 할당하는 효과를 가져온다. 또한 (program) break를 감소시키면 메모리 할당이 해제된다.
  • [출처](https://aidencom.tistory.com/208#:~:text=sbrk()%20%EB%8A%94%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%A8%EC%9D%98,%EC%9C%84%EC%B9%98%EB%A5%BC%20%EC%B0%BE%EC%9D%84%20%EB%95%8C%20%EC%93%B0%EC%9D%B8%EB%8B%A4.)

[minkukjo]

총평

• 대학생 시절이 새록새록 떠오르는 하드웨어 파트였다.
• 이번 챕터는 뭔가, "너네 JVM 개발자들 잘 들어. 이런 근본 지식이 중요하단 말이야 알겠어?"라는 느낌의 챕터였다.
• 새롭게 알게된 내용만 따로 정리해봄.

캐시 일관성 프로토콜

• 메모리에 있는 데이터를 어떻게 캐시에 가져오고, 캐시한 데이터를 어떻게 메모리에 다시 써야하는지에 대한 프로토콜.
• MESI라는 프로토콜이 가장 유명하다고 함.
• MESI는 Modified, Exclusive, Shared, Invalid 네 가지 상태로 정의한다고 함.
• 서비스 레이어에선 주로 wirte-through를 많이 쓰는데 하드웨어 단에서는 wirte-back을 주로 쓴다는 점이 신기했다. ( 물론 인스타그램처럼 초대규모 트래픽 환경에선 write-back을 쓰는게 이점이 많을 것 같긴 함. )

변환 색인 버퍼 ( TLB )

• Translation Loockaside Buffer ( TLB )는 가상 메모리 주소를 물리 메모리 주소로 매핑하는 페이지 테이블의 캐시. ( 4년전 취준할 때 공부했었는데 풀 네임을 오늘에서야 알았다. )

추측 실행의 보안이슈에 관하여

if (a > 16)    
    b = 32

• 추측 실행은 a라는 값을 가져오는데 시간이 걸리기 때문에, 일단 b에 32를 넣어두고 a가 16보다 크면 실행할 수 있다고 한다.
• 이 추측 실행은 아래와 같은 시나리오에서 커널 메모리를 읽어갈 수 있는 멜트다운 취약점을 갖고 있다고 합니다!?

raise_exception();
// the line below is never reached
access(probe_array[data * 4096]);

1. raise_exception() 함수가 실행됩니다.

2. 순차적 실행에서는 3번 줄이 실행되지 않지만, 비순차적 실행으로 인하여 3번째 줄이 실행되게 됩니다.

3. raise_exception() 함수에 의해 예외가 발생하고 제어 흐름이 운영체제의 예외 처리기로 점프합니다.

4. 예외로 인해서 순서에 맞지 않게 실행된 명령은 폐기되지 않습니다.

5. 이 예외가 메모리 액세스 또는 다른 CPU 예외로 인해 발생했는지 여부에 관계없이 제어 흐름은 다음 사용자 공간 명령이 아닌 커널에서 계속됩니다.

6. 커널에서 실행이 되게 되고 캐시에 데이터가 올라가게 됩니다.

• 출처 : https://rmagur1203.tistory.com/17

분기 예측의 보안 이슈

• 분기 예측도 스펙터(아이콘이 꽤나 카와이함) 취약점이 있다고 하는데요.
• 분기 예측 보안 이슈는 예제를 봐도 이해가 잘 안가서 패스.. 역시 보안쪽은 어렵군요;

스케쥴러

• 프로세서 스케쥴러가 이렇게 까지 비효율적일 줄은 몰랐다.
• 스레드가 잠들면 OS가 해당 스레드가 그 잠에서 깨어날 때 까지 ( 실행 큐 가장 앞으로 올 때 까지 )대기해야한다는 점이 신기했다. ( 뭔가 리액티브 스럽게는 안될까요..? ㅎ )

컨텍스트 스위칭

• 리눅스의 시스템 콜을 호출하게 되면 유저 모드에서 커널 모드로 바뀌면서 컨텍스트 스위칭이 일어난다고 합니다.
• 이 경우 당연히 TLB를 비롯한 모든 캐시가 컨텍스트 스위칭이 일어날 때 비워지게 되는데, 이것이 시스템 콜이 비싼 이유라는 것을 알게 되었네요.
• 리눅스에서는 가상 동적 공유 객체 ( Virtual Dynamically Shared Object )라는 장치를 제공해서 커널 권한이 없는 시스템 콜의 속도를 높이려고 쓰는 유저 모드의 메모리 영역이라고 합니다. 유저 모드에서 커널 모드로 컨텍스트 스위칭이 일어나지 않아서 속도가 빠르다고 하네요.

감지 전략

• vmstart 1 : CPU 사용률 지표를 나타내줍니다.
• 운영 환경에선 GC 로그를 남겨야한다고 하네요. (우리 남기던가..? 긁적)

[HaeUlNam]

정리

무어의 법칙: 대량 생산한 칩상의 트랜지스터 수는 약 18개월마다 2배씩 증가한다.

→ 컴퓨터 파워가 기하급수적으로 증가. Application 개발자, 자바는 만은 혜택을 받았다. 하지만, 성능을 진지하게 고민하는 프로그래머라면, 가용 리소스를 최대한 활용할 수 있도록 자바 플랫폼의 원리와 기술을 잘 알아야 한다.

무어의 법칙에 따라 급증한 트랜지스터는 처음엔 클록 속도를 높이는데 쓰였다(클록 속도가 증가하면 초당 더 많은 명령어를 처리할 수 있기 때문)

문제점: CPU와 메모리 간의 성능 차이로 인해, 클럭 속도가 올라가더라도 데이터 전송 완료까지 CPU가 노는 일이 발생

• 해결책: Main memory와 Register 사이에 CPU 캐시(L1/L2/L3)를 두어 자주 액세스하는 메모리 위치는 CPU가 매번 메인 메모리를 재참조하지 않게 캐싱함. 이를 통해, 프로세서 처리율은 현저히 개선
• 일반적으로 각 실행 코어에 전용 Private 캐시 L1/L2를 두고, 일부 또는 전체 코어가 공유한 L3 캐시를 둔다.

문제점: 메모리에 있는 데이터를 어떻게 캐시로 가져오고, 캐시한 데이터를 어떻게 메모리에 써야 할지

• 해결책: 캐시 일관성 프로토콜(Cache Consistency protocol)으로 해결.
• MESI protocol
  • Modified: 데이터 수정 상태
  • Exclusive: 이 캐시에만 존재하고 메인 메모리 내용과 동일한 상태
  • Shared: 둘 이상의 캐시에 데이터가 들어 있고 메모리 내용과 동일한 상태
  • Invalid: 다른 프로세스가 데이터를 수정하여 무효한 상태
• 멀티 프로세서가 동시에 공유 상태에 있을 수 있고, 어느 한 프로세서가 배타(Exclusive)나 수정(Modified) 상태가 되면, 다른 프로세서는 모두 강제로 무효 상태가 된다.

캐시 Write 방식

• Write-through: 캐시 연산 결과를 바로 메모리에 기록. 메모리 대역폭을 너무 많이 씀
• Write-back: 캐시 블록을 교체해도 프로세서가 변경된(더티) 캐시 블록만 메모리에 기록하므로 메인 메모리로 되돌아가는 트래픽이 뚝 떨어짐

TLB(Translation Lookaside Buffer)

가상 메모리 주소를 물리 메모리 주소로 매핑하는 페이지 테이블의 캐시 역할을 수행

• Virtual Memory는 물리적 메모리 크기의 한계를 극복하기 위해 나온 기술이다. 현재 필요한 Paging만 메모리에 두고(Demand Paging), 필요없는 것은 Disk에 두어 프로세스 전체가 물리적 메모리에 있는 것처럼 수행
• https://rebro.kr/179

Branch Prediction

• 프로세서가 조건 분기하는 기준값을 평가하느라 대기하는 현상을 방지. 왜냐하면 분기 예측이 없다면, Processor는 조건부 점프 명령이 실행 단계를 통과할 때까지 기다려야 다음 명령이 파이프라인에 들어갈 수 있다.
• Branch misprediction: 다만, 조건문을 다 평가하기 전까지는 분기 이후 다음 명령을 알 수 없는 것이 문제. Branch misprediction이 발생하면 최대 20회를 낭비
• Spectre 공격 - Intel 2018

공격자는 희생자 프로세스에서 분기 명령을 수행할 때 분기할 목적지를 잘못 예측하게 유도하고 잘못 예측된 데이터가 Speculative execution에 의해 캐시에 적재되면 Flush + Reload 공격을 이용하여 데이터를 유출한다.

Flush + Reload 공격: Flush + Reload 공격을 위해 공격자는 LLC(Last Level Cache)를 모든 코어에서 공유하고 있다는 점을 이용한다. LLC는 모든 코어에서 공유하고 있기 때문에 캐시의 일관성을 유지하기 위해 LLC에서 데이터가 제거되면 다른 모든 코어에서도 데이터가 제거된다.이러한 특성을 악용하여 공격자는 LLC의 모든 Cache Line을 clflush() 명령을 이용하여 제거한다. 이 상태에서 희생자가 어떤 메모리에 접근하면 희생자가 접근한 메모리 주소만 유일하게 캐시에 적재된다. 공격자는 일반적인 방법으로는 캐시에 적재된 데이터를 유출할 수 없기 때문에 메모리 접근 속도를 이용한다. 공격자는 데이터를 유출하기 위해 희생자가 접근한 메모리 주소에 접근한다. 공격자가 접근한 메모리 주소가 희생자가 접근했던 메모리 주소라면 캐시에 적재되어 있기 때문에 접근 속도가 매우 빠르지만, 희생자가 접근하지 않았던 메모리 주소라면 접근 속도가 전자보다 상대적으로 느리다. 공격자는 유출하려는 데이터를 메모리 주소의 index로 이용하여 유출하려는 데이터가 캐시에 적재되도록 만든 후 메모리 주소의 index에 다시 접근하여 데이터를 유출한다

• https://koreascience.kr/article/JAKO202013661038812.pdf

더 알아본 내용

Cache Hit/Miss 관점에서의 MESI protocol

• Exclusive/Modified 상태: Cache Hit, Cache가 해당 블록을 가지고 있기 때문에 Read/Write 요청을 모두 Cache에서 처리가능하다.
• Invalid 상태: Cache Miss, 다만 모든 경우에 main memory를 통해서 데이터를 가져오는 것이 아니라 다른 Processor에 있다면 Bus를 통해 데이터를 가져온다.
• Shared 상태: Read는 Cache Hit. Write는 다른 Cache copy에 접근해서 Invalid 상태로 바꿔야 한다.

Bus snooping

Coherency controller(Snooper)가 Cache 일관성을 유지하기 위해 Bus transaction을 monitoring 하는 체계.

• Snooping protocol 종류
  • Write-invalidation: 어떤 Processor가 shared cache block에 write를 한다면, 나머지 cache block들은 invalidate. 이 방식은 하나의 Copy에서 exclusively Read/Write할 수 있다.
  • Write-update: 어떤 Processor가 shared cache block에 write를 한다면, 나머지 cache block들은 bus snpooing을 통해 update. Write-invalidate protocol보다 더 큰 bus traffic을 요구한다. 그렇기에 Write-invalidation가 더 common한 방식으로 사용된다(아마 성능 이슈..?)

MSI vs MESI vs MOESI

• MSI vs MESI: MESI 이전에는 MSI를 사용했었다. 이 때는 Exclusive 상태가 존재하지 않았고, 이 캐시에만 존재한 경우 Shared state로 관리했다. 그렇기에 MESI와 다르게 MSI는 하나의 Processor 내부에서만 처리할 수 있는 경우에도 불필요하게 Bus Transaction이 발생.
  • Exclusive 상태를 도입함으로써 Write opreation에서 Cache Hit를 통해 Performance 상승
• MESI vs MOESI: MESI에서는 변경한 Cache line을 다른 Processor에서 읽기 요청했을 때, 메모리에 Write-back했는데, MOESI에서는 이 경우 메모리에 Write back 하지 않고 바로 데이터를 넘겨주도록 하는 Owned 상태를 추가했다.
  • Owned: 현재 processor는 변경된 최신 데이터를 가지고 있고, 다른 processor에서도 해당 데이터를 Shared 상태로 가지고 있지만 아직 메모리에 write되지는 않았다.
  • Modify 상태에서 다른 Processor가 해당 데이터를 요청했을 때 Owned 상태가 된다.

→ 대부분의 ARM processor들은 MOESI를 사용한다고 한다.

• Reference
  • http://egloos.zum.com/studyfoss/v/5144244
  • https://en.wikipedia.org/wiki/MESI_protocol
  • https://tot0rokr.github.io/arm64/cache/moesi-protocol/
  • https://developer.arm.com/documentation/den0013/d/Multi-core-processors/Cache-coherency/MESI-and-MOESI-protocols