메모리 배리어: 다른 CPU와 장치는 무엇을 보게 됩니까?

누가 어떤 두 동작을 순서대로 보아야 합니까?

“배리어를 넣었다”는 말만으로는 충분하지 않습니다. 데이터를 읽는 주체가 다른 CPU인지, DMA 장치인지, 주소 변환을 수행하는 하드웨어인지부터 정해야 합니다. 같은 주소처럼 보여도 일반 RAM과 장치 register는 접근 방법이 다릅니다.

배리어는 데이터를 대신 복사하거나 여러 writer의 충돌을 자동으로 막는 기능이 아닙니다. 순서가 맞아도 객체를 너무 일찍 해제하면 잘못된 메모리를 읽습니다.

READ_ONCE만 있으면 준비된 값을 읽습니까?

다음은 Linux 커널 안의 설명용 예입니다. producer와 consumer는 일반 cacheable RAM의 같은 payload·ready를 공유합니다. 두 변수는 실행을 시작하기 전에 0으로 초기화됐고, producer는 한 번만 공개하며 이후 payload를 바꾸지 않습니다. consumer가 끝날 때까지 변수의 수명도 유지합니다.

/* producer: 한 번만 실행합니다. */
WRITE_ONCE(payload, 0x55);
smp_store_release(&ready, 1);

/* consumer: out은 호출자가 제공한 유효한 출력 공간입니다. */
if (!smp_load_acquire(&ready))
    return false;
*out = READ_ONCE(payload);
return true;

ready를 읽는 쪽도 같은 공개 규칙에 참여해야 합니다. ready를 다시 0으로 돌려 여러 메시지에 재사용하거나 producer가 여러 개라면 이 짧은 예제만으로 충분하지 않습니다. 새 값과 이전 값을 구별하는 protocol과 덮어쓰기·회수 조건을 추가해야 합니다. release·acquire의 순서

표시와 데이터가 따로 보이는 문제를 그려 봅니다

v6.18.37의 공식 message-passing litmus 파일도 순서 없는 예에는 Sometimes, 쓰기·읽기 배리어를 짝지은 예에는 Never라는 기대 결과를 적고 있습니다. 여기서는 그 소스와 보장 조건을 대조했으며, 이 장치에서 herd7이나 실제 CPU 시험을 수행한 결과로 제시하지 않습니다. 순서 없는 공식 예 배리어를 짝지은 공식 예

SMP 설정과 빈 어셈블리를 읽는 방법

CONFIG_SMP는 여러 CPU가 함께 실행되는 커널을 구성하는 빌드 설정입니다. 지금 online CPU가 몇 개인지 검사하는 if 문이 아닙니다. include/asm-generic/barrier.h는 이미 architecture 쪽에서 정의한 구현을 우선 사용하고, 없는 정의를 보충합니다.

CPU가 하나인 커널에서도 DMA 장치는 CPU와 별도로 동작합니다. 장치에 보이는 접근 순서와 MMIO 규칙을 고려해야 하므로 “UP이면 compiler barrier 외에는 필요 없다”는 결론은 맞지 않습니다. 가상 머신도 guest의 CPU 수와 host의 공유 메모리 처리가 다를 수 있어 virt_* 계열을 구분합니다. SMP·UP·virt 배리어 선택 compiler barrier 정의 arm64 구현 x86 구현

descriptor 준비, 장치 알림, 작업 완료는 다릅니다

descriptor는 장치가 수행할 작업의 주소·길이·상태 등을 담는 설명 구조체입니다. 여기서는 CPU와 장치가 coherent DMA 메모리의 descriptor를 공유하고, status가 소유권을 나타내는 장치를 가정합니다. streaming DMA buffer의 cache 처리는 별도의 mapping·sync 규칙을 따릅니다.

dma_* 배리어가 MMIO 접근 순서까지 대신 보장하는 것은 아닙니다. 장치 register에는 적절한 I/O accessor를 사용합니다. coherent는 CPU와 장치의 cache 일관성 조건이며, descriptor 필드의 순서와 사용 권한까지 자동으로 정하지 않습니다. DMA 배리어와 I/O accessor의 구분

writel이 반환하면 장치의 일도 끝났습니까?

bus에 따라 write를 중간에서 받아 두고 나중에 전달하는 posted write가 있습니다. 이 경우 CPU 함수의 반환과 장치가 쓰기를 받는 시점을 구분해야 합니다. 전달을 확인해야 하는 지점에서는 해당 장치·bus 규칙에 맞는 안전한 register를 readl로 읽는 방법 등이 사용됩니다.

spinlock을 잡았다는 사실만으로 posted write가 장치에 도착한 시점까지 자동으로 정해지지는 않습니다. writel_relaxed로 바꾸는 것도 단순한 속도 조정이 아닙니다. 생략되는 순서 보장을 다른 코드가 어떻게 충족하는지 먼저 확인합니다. I/O write와 posted write 잠금 구간과 안전한 readback

cache 처리와 TLB 무효화를 혼동하지 않습니다

D-cache는 데이터, I-cache는 실행할 명령, TLB는 주소 변환과 권한에 관한 상태를 다룹니다. 메모리 배리어를 실행했다고 이 상태들이 모두 갱신되는 것은 아닙니다. PTE는 페이지 테이블 항목이며 RAM에 저장된 값입니다. 그 값을 고쳐도 하드웨어에 남은 옛 변환은 별도 처리 대상입니다.

기존 주소 매핑으로 cache 작업을 해야 하는 architecture를 고려해 Linux의 공통 문서는 cache 처리 → PTE 변경 → TLB 처리를 설명합니다. 모든 CPU에서 모든 cache helper가 실제 cache line을 비우는 명령을 낸다는 뜻은 아닙니다. 새 실행 코드를 쓴 경우의 I-cache 동기화 역시 별도로 확인합니다. cache·PTE·TLB 처리 순서 arm64 cache helper의 목적

Linux 4.18 문서를 현재 코드와 대조할 때

4.18의 Cache and TLB Flushing 문서는 역할을 이해하는 데 도움이 되지만 함수 이름과 인자까지 현재 코드로 옮기면 안 됩니다. v6.18.37 문서는 update_mmu_cache_range(vmf, vma, address, ptep, nr)를 설명하며, nr은 연속된 페이지 수입니다. 예전 문서의 update_mmu_cache와 인자 목록이 다릅니다. 이 API를 모든 architecture에서 TLB 항목을 강제로 채우는 함수로 단정하지도 않습니다.

TLBI·INVLPG·SFENCE.VMA의 상세 명령 분석은 기존 글과 연결했습니다. 이 글에서 보충한 부분은 누가 값을 관찰하는지, 어느 저장과 읽기를 연결해야 하는지, 요청·도착·완료를 어디서 구분하는지입니다. v6.18.37 API 설명 실제 arm64 TLB helper

이어서 읽기

• DMA buffer의 주소·mapping·수명
• RCU 객체 공개와 회수
• 완료 통지와 timeout
• blog/kernel/arch-cache-barrier-6-18-lts.html
• Cache coherency와 memory barrier: DMB/DSB, x86 ordering, FENCE
• blog/kernel/arch-tlb-shootdown-6-18-lts.html
• TLB shootdown: TLBI, INVLPG/INVPCID와 SFENCE.VMA