Skip to content

Commit

Permalink
Documentation/kokr: Kill all references to mmiowb()
Browse files Browse the repository at this point in the history
Translate this commit to Korean:

  9155303 ("Documentation: Kill all references to mmiowb()")

Signed-off-by: SeongJae Park <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>
  • Loading branch information
sjp38 authored and Jonathan Corbet committed Nov 22, 2019
1 parent 2ece3e0 commit bf3b965
Showing 1 changed file with 6 additions and 98 deletions.
104 changes: 6 additions & 98 deletions Documentation/translations/ko_KR/memory-barriers.txt
Original file line number Diff line number Diff line change
Expand Up @@ -1907,21 +1907,6 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효
위해선 Documentation/DMA-API.txt 문서를 참고하세요.


MMIO 쓰기 배리어
----------------

리눅스 커널은 또한 memory-mapped I/O 쓰기를 위한 특별한 배리어도 가지고
있습니다:

mmiowb();

이것은 mandatory 쓰기 배리어의 변종으로, 완화된 순서 규칙의 I/O 영역에으로의
쓰기가 부분적으로 순서를 맞추도록 해줍니다. 이 함수는 CPU->하드웨어 사이를
넘어서 실제 하드웨어에까지 일부 수준의 영향을 끼칩니다.

더 많은 정보를 위해선 "Acquire vs I/O 액세스" 서브섹션을 참고하세요.


=========================
암묵적 커널 메모리 배리어
=========================
Expand Down Expand Up @@ -2283,73 +2268,6 @@ ACQUIRE VS 메모리 액세스
*E, *F or *G following RELEASE Q



ACQUIRE VS I/O 액세스
----------------------

특정한 (특히 NUMA 가 관련된) 환경 하에서 두개의 CPU 에서 동일한 스핀락으로
보호되는 두개의 크리티컬 섹션 안의 I/O 액세스는 PCI 브릿지에 겹쳐진 I/O
액세스로 보일 수 있는데, PCI 브릿지는 캐시 일관성 프로토콜과 합을 맞춰야 할
의무가 없으므로, 필요한 읽기 메모리 배리어가 요청되지 않기 때문입니다.

예를 들어서:

CPU 1 CPU 2
=============================== ===============================
spin_lock(Q)
writel(0, ADDR)
writel(1, DATA);
spin_unlock(Q);
spin_lock(Q);
writel(4, ADDR);
writel(5, DATA);
spin_unlock(Q);

는 PCI 브릿지에 다음과 같이 보일 수 있습니다:

STORE *ADDR = 0, STORE *ADDR = 4, STORE *DATA = 1, STORE *DATA = 5

이렇게 되면 하드웨어의 오동작을 일으킬 수 있습니다.


이런 경우엔 잡아둔 스핀락을 내려놓기 전에 mmiowb() 를 수행해야 하는데, 예를
들면 다음과 같습니다:

CPU 1 CPU 2
=============================== ===============================
spin_lock(Q)
writel(0, ADDR)
writel(1, DATA);
mmiowb();
spin_unlock(Q);
spin_lock(Q);
writel(4, ADDR);
writel(5, DATA);
mmiowb();
spin_unlock(Q);

이 코드는 CPU 1 에서 요청된 두개의 스토어가 PCI 브릿지에 CPU 2 에서 요청된
스토어들보다 먼저 보여짐을 보장합니다.


또한, 같은 디바이스에서 스토어를 이어 로드가 수행되면 이 로드는 로드가 수행되기
전에 스토어가 완료되기를 강제하므로 mmiowb() 의 필요가 없어집니다:

CPU 1 CPU 2
=============================== ===============================
spin_lock(Q)
writel(0, ADDR)
a = readl(DATA);
spin_unlock(Q);
spin_lock(Q);
writel(4, ADDR);
b = readl(DATA);
spin_unlock(Q);


더 많은 정보를 위해선 Documentation/driver-api/device-io.rst 를 참고하세요.


=========================
메모리 배리어가 필요한 곳
=========================
Expand Down Expand Up @@ -2494,14 +2412,9 @@ _않습니다_.
리눅스 커널 내부에서, I/O 는 어떻게 액세스들을 적절히 순차적이게 만들 수 있는지
알고 있는, - inb() 나 writel() 과 같은 - 적절한 액세스 루틴을 통해 이루어져야만
합니다. 이것들은 대부분의 경우에는 명시적 메모리 배리어 와 함께 사용될 필요가
없습니다만, 다음의 두가지 상황에서는 명시적 메모리 배리어가 필요할 수 있습니다:

(1) 일부 시스템에서 I/O 스토어는 모든 CPU 에 일관되게 순서 맞춰지지 않는데,
따라서 _모든_ 일반적인 드라이버들에 락이 사용되어야만 하고 이 크리티컬
섹션을 빠져나오기 전에 mmiowb() 가 꼭 호출되어야 합니다.

(2) 만약 액세스 함수들이 완화된 메모리 액세스 속성을 갖는 I/O 메모리 윈도우를
사용한다면, 순서를 강제하기 위해선 _mandatory_ 메모리 배리어가 필요합니다.
없습니다만, 완화된 메모리 액세스 속성으로 I/O 메모리 윈도우로의 참조를 위해
액세스 함수가 사용된다면 순서를 강제하기 위해 _madatory_ 메모리 배리어가
필요합니다.

더 많은 정보를 위해선 Documentation/driver-api/device-io.rst 를 참고하십시오.

Expand Down Expand Up @@ -2545,10 +2458,9 @@ _않습니다_.
인터럽트 내에서 일어난 액세스와 섞일 수 있다고 - 그리고 그 반대도 - 가정해야만
합니다.

그런 영역 안에서 일어나는 I/O 액세스들은 엄격한 순서 규칙의 I/O 레지스터에
묵시적 I/O 배리어를 형성하는 동기적 (synchronous) 로드 오퍼레이션을 포함하기
때문에 일반적으로는 이런게 문제가 되지 않습니다. 만약 이걸로는 충분치 않다면
mmiowb() 가 명시적으로 사용될 필요가 있습니다.
그런 영역 안에서 일어나는 I/O 액세스는 묵시적 I/O 배리어를 형성하는, 엄격한
순서 규칙의 I/O 레지스터로의 로드 오퍼레이션을 포함하기 때문에 일반적으로는
문제가 되지 않습니다.


하나의 인터럽트 루틴과 별도의 CPU 에서 수행중이며 서로 통신을 하는 두 루틴
Expand Down Expand Up @@ -2641,10 +2553,6 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
이 모든 액세스 함수들은 아랫단의 주변장치가 little-endian 이라 가정하며, 따라서
big-endian 아키텍쳐에서는 byte-swapping 오퍼레이션을 수행합니다.

I/O 순서 배리어를 SMP 순서 배리어와 LOCK/UNLOCK 오퍼레이션과 섞는 건 mmiowb()
를 필요로 할 수도 있는 위험한 행위입니다. 더 많은 내용을 위해선 "Acquire vs
I/O 액세스" 서브섹션을 참고하시기 바랍니다.


===================================
가정되는 가장 완화된 실행 순서 모델
Expand Down

0 comments on commit bf3b965

Please sign in to comment.