diff options
Diffstat (limited to 'Documentation/translations/ko_KR/memory-barriers.txt')
| -rw-r--r-- | Documentation/translations/ko_KR/memory-barriers.txt | 360 |
1 files changed, 126 insertions, 234 deletions
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index f07c40a068b5..7165927a708e 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -1,6 +1,6 @@ NOTE: This is a version of Documentation/memory-barriers.txt translated into Korean. -This document is maintained by SeongJae Park <sj38.park@gmail.com>. +This document is maintained by SeongJae Park <sj@kernel.org>. If you find any difference between this document and the original file or a problem with the translation, please contact the maintainer of this file. @@ -10,13 +10,13 @@ a fork. So if you have any comments or updates for this file please update the original English file first. The English version is definitive, and readers should look there if they have any doubt. -=================================== +================================= 이 문서는 Documentation/memory-barriers.txt 의 한글 번역입니다. -역자： 박성재 <sj38.park@gmail.com> -=================================== +역자： 박성재 <sj@kernel.org> +================================= ========================= @@ -80,7 +80,7 @@ Documentation/memory-barriers.txt - 메모리 배리어의 종류. - 메모리 배리어에 대해 가정해선 안될 것. - - 데이터 의존성 배리어 (역사적). + - 주소 데이터 의존성 배리어 (역사적). - 컨트롤 의존성. - SMP 배리어 짝맞추기. - 메모리 배리어 시퀀스의 예. @@ -91,7 +91,6 @@ Documentation/memory-barriers.txt - 컴파일러 배리어. - CPU 메모리 배리어. - - MMIO 쓰기 배리어. (*) 암묵적 커널 메모리 배리어. @@ -103,7 +102,6 @@ Documentation/memory-barriers.txt (*) CPU 간 ACQUIRING 배리어의 효과. - Acquire vs 메모리 액세스. - - Acquire vs I/O 액세스. (*) 메모리 배리어가 필요한 곳 @@ -219,7 +217,7 @@ Documentation/memory-barriers.txt P = &B D = *Q; D 로 읽혀지는 값은 CPU 2 에서 P 로부터 읽혀진 주소값에 의존적이기 때문에 여기엔 -분명한 데이터 의존성이 있습니다. 하지만 이 이벤트들의 실행 결과로는 아래의 +분명한 주소 의존성이 있습니다. 하지만 이 이벤트들의 실행 결과로는 아래의 결과들이 모두 나타날 수 있습니다: (Q == &A) and (D == 1) @@ -418,19 +416,19 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니 하나씩 요청해 집어넣습니다. 쓰기 배리어 앞의 모든 스토어 오퍼레이션들은 쓰기 배리어 뒤의 모든 스토어 오퍼레이션들보다 _앞서_ 수행될 겁니다. - [!] 쓰기 배리어들은 읽기 또는 데이터 의존성 배리어와 함께 짝을 맞춰 + [!] 쓰기 배리어들은 읽기 또는 주소 의존성 배리어와 함께 짝을 맞춰 사용되어야만 함을 알아두세요; "SMP 배리어 짝맞추기" 서브섹션을 참고하세요. - (2) 데이터 의존성 배리어. + (2) 주소 의존성 배리어 (역사적). - 데이터 의존성 배리어는 읽기 배리어의 보다 완화된 형태입니다. 두개의 로드 + 주소 의존성 배리어는 읽기 배리어의 보다 완화된 형태입니다. 두개의 로드 오퍼레이션이 있고 두번째 것이 첫번째 것의 결과에 의존하고 있을 때(예: 두번째 로드가 참조할 주소를 첫번째 로드가 읽는 경우), 두번째 로드가 읽어올 데이터는 첫번째 로드에 의해 그 주소가 얻어진 뒤에 업데이트 됨을 보장하기 - 위해서 데이터 의존성 배리어가 필요할 수 있습니다. + 위해서 주소 의존성 배리어가 필요할 수 있습니다. - 데이터 의존성 배리어는 상호 의존적인 로드 오퍼레이션들 사이의 부분적 순서 + 주소 의존성 배리어는 상호 의존적인 로드 오퍼레이션들 사이의 부분적 순서 세우기입니다; 스토어 오퍼레이션들이나 독립적인 로드들, 또는 중복되는 로드들에 대해서는 어떤 영향도 끼치지 않습니다. @@ -438,37 +436,41 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니 오퍼레이션들을 던져 넣고 있으며, 거기에 관심이 있는 다른 CPU 는 그 오퍼레이션들을 메모리 시스템이 실행한 결과를 인지할 수 있습니다. 이처럼 다른 CPU 의 스토어 오퍼레이션의 결과에 관심을 두고 있는 CPU 가 수행 요청한 - 데이터 의존성 배리어는, 배리어 앞의 어떤 로드 오퍼레이션이 다른 CPU 에서 + 주소 의존성 배리어는, 배리어 앞의 어떤 로드 오퍼레이션이 다른 CPU 에서 던져 넣은 스토어 오퍼레이션과 같은 영역을 향했다면, 그런 스토어 - 오퍼레이션들이 만들어내는 결과가 데이터 의존성 배리어 뒤의 로드 + 오퍼레이션들이 만들어내는 결과가 주소 의존성 배리어 뒤의 로드 오퍼레이션들에게는 보일 것을 보장합니다. 이 순서 세우기 제약에 대한 그림을 보기 위해선 "메모리 배리어 시퀀스의 예" 서브섹션을 참고하시기 바랍니다. - [!] 첫번째 로드는 반드시 _데이터_ 의존성을 가져야지 컨트롤 의존성을 가져야 + [!] 첫번째 로드는 반드시 _주소_ 의존성을 가져야지 컨트롤 의존성을 가져야 하는게 아님을 알아두십시오. 만약 두번째 로드를 위한 주소가 첫번째 로드에 의존적이지만 그 의존성은 조건적이지 그 주소 자체를 가져오는게 아니라면, 그것은 _컨트롤_ 의존성이고, 이 경우에는 읽기 배리어나 그보다 강력한 무언가가 필요합니다. 더 자세한 내용을 위해서는 "컨트롤 의존성" 서브섹션을 참고하시기 바랍니다. - [!] 데이터 의존성 배리어는 보통 쓰기 배리어들과 함께 짝을 맞춰 사용되어야 + [!] 주소 의존성 배리어는 보통 쓰기 배리어들과 함께 짝을 맞춰 사용되어야 합니다; "SMP 배리어 짝맞추기" 서브섹션을 참고하세요. + [!] 커널 v5.9 릴리즈에서 명시적 주소 의존성 배리어를 위한 커널 API 들이 + 삭제되었습니다. 오늘날에는 공유된 변수들의 로드를 표시하는 READ_ONCE() 나 + rcu_dereference() 와 같은 API 들은 묵시적으로 주소 의존성 배리어를 제공합니다. + (3) 읽기 (또는 로드) 메모리 배리어. - 읽기 배리어는 데이터 의존성 배리어 기능의 보장사항에 더해서 배리어보다 - 앞서 명시된 모든 LOAD 오퍼레이션들이 배리어 뒤에 명시되는 모든 LOAD + 읽기 배리어는 주소 의존성 배리어 기능의 보장사항에 더해서 배리어보다 앞서 + 명시된 모든 LOAD 오퍼레이션들이 배리어 뒤에 명시되는 모든 LOAD 오퍼레이션들보다 먼저 행해진 것으로 시스템의 다른 컴포넌트들에 보여질 것을 보장합니다. 읽기 배리어는 로드 오퍼레이션에 행해지는 부분적 순서 세우기입니다; 스토어 오퍼레이션에 대해서는 어떤 영향도 끼치지 않습니다. - 읽기 메모리 배리어는 데이터 의존성 배리어를 내장하므로 데이터 의존성 - 배리어를 대신할 수 있습니다. + 읽기 메모리 배리어는 주소 의존성 배리어를 내장하므로 주소 의존성 배리어를 + 대신할 수 있습니다. [!] 읽기 배리어는 일반적으로 쓰기 배리어들과 함께 짝을 맞춰 사용되어야 합니다; "SMP 배리어 짝맞추기" 서브섹션을 참고하세요. @@ -515,14 +517,13 @@ CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니 완료되기 전에 행해진 것처럼 보일 수 있습니다. ACQUIRE 와 RELEASE 오퍼레이션의 사용은 일반적으로 다른 메모리 배리어의 - 필요성을 없앱니다 (하지만 "MMIO 쓰기 배리어" 서브섹션에서 설명되는 예외를 - 알아두세요). 또한, RELEASE+ACQUIRE 조합은 범용 메모리 배리어처럼 동작할 - 것을 보장하지 -않습니다-. 하지만, 어떤 변수에 대한 RELEASE 오퍼레이션을 - 앞서는 메모리 액세스들의 수행 결과는 이 RELEASE 오퍼레이션을 뒤이어 같은 - 변수에 대해 수행된 ACQUIRE 오퍼레이션을 뒤따르는 메모리 액세스에는 보여질 - 것이 보장됩니다. 다르게 말하자면, 주어진 변수의 크리티컬 섹션에서는, 해당 - 변수에 대한 앞의 크리티컬 섹션에서의 모든 액세스들이 완료되었을 것을 - 보장합니다. + 필요성을 없앱니다. 또한, RELEASE+ACQUIRE 조합은 범용 메모리 배리어처럼 + 동작할 것을 보장하지 -않습니다-. 하지만, 어떤 변수에 대한 RELEASE + 오퍼레이션을 앞서는 메모리 액세스들의 수행 결과는 이 RELEASE 오퍼레이션을 + 뒤이어 같은 변수에 대해 수행된 ACQUIRE 오퍼레이션을 뒤따르는 메모리 + 액세스에는 보여질 것이 보장됩니다. 다르게 말하자면, 주어진 변수의 + 크리티컬 섹션에서는, 해당 변수에 대한 앞의 크리티컬 섹션에서의 모든 + 액세스들이 완료되었을 것을 보장합니다. 즉, ACQUIRE 는 최소한의 "취득" 동작처럼, 그리고 RELEASE 는 최소한의 "공개" 처럼 동작한다는 의미입니다. @@ -570,20 +571,24 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE [*] 버스 마스터링 DMA 와 일관성에 대해서는 다음을 참고하시기 바랍니다: Documentation/driver-api/pci/pci.rst - Documentation/DMA-API-HOWTO.txt - Documentation/DMA-API.txt + Documentation/core-api/dma-api-howto.rst + Documentation/core-api/dma-api.rst -데이터 의존성 배리어 (역사적) ------------------------------ +주소 의존성 배리어 (역사적) +--------------------------- -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에 +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다. -그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성 +그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 주소 의존성 배리어에 대한 이야기를 적습니다. -데이터 의존성 배리어의 사용에 있어 지켜야 하는 사항들은 약간 미묘하고, 데이터 +[!] 주소 의존성은 로드에서 로드로와 로드에서 스토어로의 관계들 모두에서 +나타나지만, 주소 의존성 배리어는 로드에서 스토어로의 상황에서는 필요하지 +않습니다. + +주소 의존성 배리어의 사용에 있어 지켜야 하는 사항들은 약간 미묘하고, 데이터 의존성 배리어가 사용되어야 하는 상황도 항상 명백하지는 않습니다. 설명을 위해 다음의 이벤트 시퀀스를 생각해 봅시다: @@ -593,10 +598,13 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE B = 4; <쓰기 배리어> WRITE_ONCE(P, &B) - Q = READ_ONCE(P); + Q = READ_ONCE_OLD(P); D = *Q; -여기엔 분명한 데이터 의존성이 존재하므로, 이 시퀀스가 끝났을 때 Q 는 &A 또는 &B +[!] READ_ONCE_OLD() 는 4.15 커널 전의 버전에서의, 주소 의존성 배리어를 내포하지 +않는 READ_ONCE() 에 해당합니다. + +여기엔 분명한 주소 의존성이 존재하므로, 이 시퀀스가 끝났을 때 Q 는 &A 또는 &B 일 것이고, 따라서: (Q == &A) 는 (D == 1) 를, @@ -611,8 +619,8 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 그렇지 않습니다, 그리고 이 현상은 (DEC Alpha 와 같은) 여러 CPU 에서 실제로 발견될 수 있습니다. -이 문제 상황을 제대로 해결하기 위해, 데이터 의존성 배리어나 그보다 강화된 -무언가가 주소를 읽어올 때와 데이터를 읽어올 때 사이에 추가되어야만 합니다: +이 문제 상황을 제대로 해결하기 위해, READ_ONCE() 는 커널 v4.15 릴리즈 부터 +묵시적 주소 의존성 배리어를 제공합니다: CPU 1 CPU 2 =============== =============== @@ -621,7 +629,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE <쓰기 배리어> WRITE_ONCE(P, &B); Q = READ_ONCE(P); - <데이터 의존성 배리어> + <묵시적 주소 의존성 배리어> D = *Q; 이 변경은 앞의 처음 두가지 결과 중 하나만이 발생할 수 있고, 세번째의 결과는 @@ -637,11 +645,11 @@ P 는 짝수 번호 캐시 라인에 저장되어 있고, 변수 B 는 홀수 중이라면 포인터 P (&B) 의 새로운 값과 변수 B 의 기존 값 (2) 를 볼 수 있습니다. -의존적 쓰기들의 순서를 맞추는데에는 데이터 의존성 배리어가 필요치 않은데, 이는 +의존적 쓰기들의 순서를 맞추는데에는 주소 의존성 배리어가 필요치 않은데, 이는 리눅스 커널이 지원하는 CPU 들은 (1) 쓰기가 정말로 일어날지, (2) 쓰기가 어디에 이루어질지, 그리고 (3) 쓰여질 값을 확실히 알기 전까지는 쓰기를 수행하지 않기 때문입니다. 하지만 "컨트롤 의존성" 섹션과 -Documentation/RCU/rcu_dereference.txt 파일을 주의 깊게 읽어 주시기 바랍니다: +Documentation/RCU/rcu_dereference.rst 파일을 주의 깊게 읽어 주시기 바랍니다: 컴파일러는 매우 창의적인 많은 방법으로 종속성을 깰 수 있습니다. CPU 1 CPU 2 @@ -650,12 +658,12 @@ Documentation/RCU/rcu_dereference.txt 파일을 주의 깊게 읽어 주시기 B = 4; <쓰기 배리어> WRITE_ONCE(P, &B); - Q = READ_ONCE(P); + Q = READ_ONCE_OLD(P); WRITE_ONCE(*Q, 5); -따라서, Q 로의 읽기와 *Q 로의 쓰기 사이에는 데이터 종속성 배리어가 필요치 -않습니다. 달리 말하면, 데이터 종속성 배리어가 없더라도 다음 결과는 생기지 -않습니다: +따라서, Q 로의 읽기와 *Q 로의 쓰기 사이에는 주소 의존성 배리어가 필요치 +않습니다. 달리 말하면, 오늘날의 READ_ONCE() 의 묵시적 주소 의존성 배리어가 +없더라도 다음 결과는 생기지 않습니다: (Q == &B) && (B == 4) @@ -666,16 +674,16 @@ Documentation/RCU/rcu_dereference.txt 파일을 주의 깊게 읽어 주시기 해줍니다. -데이터 의존성에 의해 제공되는 이 순서규칙은 이를 포함하고 있는 CPU 에 +주소 의존성에 의해 제공되는 이 순서규칙은 이를 포함하고 있는 CPU 에 지역적임을 알아두시기 바랍니다. 더 많은 정보를 위해선 "Multicopy 원자성" 섹션을 참고하세요. -데이터 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다. +주소 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다. include/linux/rcupdate.h 의 rcu_assign_pointer() 와 rcu_dereference() 를 -참고하세요. 여기서 데이터 의존성 배리어는 RCU 로 관리되는 포인터의 타겟을 현재 -타겟에서 수정된 새로운 타겟으로 바꾸는 작업에서 새로 수정된 타겟이 초기화가 -완료되지 않은 채로 보여지는 일이 일어나지 않게 해줍니다. +참고하세요. 이것들은 RCU 로 관리되는 포인터의 타겟을 현재 타겟에서 수정된 +새로운 타겟으로 바꾸는 작업에서 새로 수정된 타겟이 초기화가 완료되지 않은 채로 +보여지는 일이 일어나지 않게 해줍니다. 더 많은 예를 위해선 "캐시 일관성" 서브섹션을 참고하세요. @@ -687,16 +695,17 @@ include/linux/rcupdate.h 의 rcu_assign_pointer() 와 rcu_dereference() 를 약간 다루기 어려울 수 있습니다. 이 섹션의 목적은 여러분이 컴파일러의 무시로 인해 여러분의 코드가 망가지는 걸 막을 수 있도록 돕는겁니다. -로드-로드 컨트롤 의존성은 데이터 의존성 배리어만으로는 정확히 동작할 수가 -없어서 읽기 메모리 배리어를 필요로 합니다. 아래의 코드를 봅시다: +로드-로드 컨트롤 의존성은 (묵시적인) 주소 의존성 배리어만으로는 정확히 동작할 +수가 없어서 읽기 메모리 배리어를 필요로 합니다. 아래의 코드를 봅시다: q = READ_ONCE(a); + <묵시적 주소 의존성 배리어> if (q) { - <데이터 의존성 배리어> /* BUG: No data dependency!!! */ + /* BUG: No address dependency!!! */ p = READ_ONCE(b); } -이 코드는 원하는 대로의 효과를 내지 못할 수 있는데, 이 코드에는 데이터 의존성이 +이 코드는 원하는 대로의 효과를 내지 못할 수 있는데, 이 코드에는 주소 의존성이 아니라 컨트롤 의존성이 존재하기 때문으로, 이런 상황에서 CPU 는 실행 속도를 더 빠르게 하기 위해 분기 조건의 결과를 예측하고 코드를 재배치 할 수 있어서 다른 CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레이션보다 먼저 발생한 @@ -933,9 +942,9 @@ CPU 간 상호작용을 다룰 때에 일부 타입의 메모리 배리어는 범용 배리어들은 범용 배리어끼리도 짝을 맞추지만 multicopy 원자성이 없는 대부분의 다른 타입의 배리어들과도 짝을 맞춥니다. ACQUIRE 배리어는 RELEASE 배리어와 짝을 맞춥니다만, 둘 다 범용 배리어를 포함해 다른 배리어들과도 짝을 -맞출 수 있습니다. 쓰기 배리어는 데이터 의존성 배리어나 컨트롤 의존성, ACQUIRE +맞출 수 있습니다. 쓰기 배리어는 주소 의존성 배리어나 컨트롤 의존성, ACQUIRE 배리어, RELEASE 배리어, 읽기 배리어, 또는 범용 배리어와 짝을 맞춥니다. -비슷하게 읽기 배리어나 컨트롤 의존성, 또는 데이터 의존성 배리어는 쓰기 배리어나 +비슷하게 읽기 배리어나 컨트롤 의존성, 또는 주소 의존성 배리어는 쓰기 배리어나 ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추는데, 다음과 같습니다: @@ -954,7 +963,7 @@ ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추 a = 1; <쓰기 배리어> WRITE_ONCE(b, &a); x = READ_ONCE(b); - <데이터 의존성 배리어> + <묵시적 주소 의존성 배리어> y = *x; 또는: @@ -973,8 +982,8 @@ ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추 기본적으로, 여기서의 읽기 배리어는 "더 완화된" 타입일 순 있어도 항상 존재해야 합니다. -[!] 쓰기 배리어 앞의 스토어 오퍼레이션은 일반적으로 읽기 배리어나 데이터 -의존성 배리어 뒤의 로드 오퍼레이션과 매치될 것이고, 반대도 마찬가지입니다: +[!] 쓰기 배리어 앞의 스토어 오퍼레이션은 일반적으로 읽기 배리어나 주소 의존성 +배리어 뒤의 로드 오퍼레이션과 매치될 것이고, 반대도 마찬가지입니다: CPU 1 CPU 2 =================== =================== @@ -1026,7 +1035,7 @@ ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추 V -둘째, 데이터 의존성 배리어는 데이터 의존적 로드 오퍼레이션들의 부분적 순서 +둘째, 주소 의존성 배리어는 데이터 의존적 로드 오퍼레이션들의 부분적 순서 세우기로 동작합니다. 다음 일련의 이벤트들을 보세요: CPU 1 CPU 2 @@ -1072,7 +1081,7 @@ ACQUIRE 배리어, RELEASE 배리어, 또는 범용 배리어와 짝을 맞추 앞의 예에서, CPU 2 는 (B 의 값이 될) *C 의 값 읽기가 C 의 LOAD 뒤에 이어짐에도 B 가 7 이라는 결과를 얻습니다. -하지만, 만약 데이터 의존성 배리어가 C 의 로드와 *C (즉, B) 의 로드 사이에 +하지만, 만약 주소 의존성 배리어가 C 의 로드와 *C (즉, B) 의 로드 사이에 있었다면: CPU 1 CPU 2 @@ -1083,7 +1092,7 @@ B 가 7 이라는 결과를 얻습니다. <쓰기 배리어> STORE C = &B LOAD X STORE D = 4 LOAD C (gets &B) - <데이터 의존성 배리어> + <주소 의존성 배리어> LOAD *C (reads B) 다음과 같이 됩니다: @@ -1106,7 +1115,7 @@ B 가 7 이라는 결과를 얻습니다. | +-------+ | | | | X->9 |------>| | | +-------+ | | - C 로의 스토어 앞의 ---> \ ddddddddddddddddd | | + C 로의 스토어 앞의 ---> \ aaaaaaaaaaaaaaaaa | | 모든 이벤트 결과가 \ +-------+ | | 뒤의 로드에게 ----->| B->2 |------>| | 보이게 강제한다 +-------+ | | @@ -1294,7 +1303,7 @@ A 의 로드 두개가 모두 B 의 로드 뒤에 있지만, 서로 다른 값 즉각 완료한다 : : +-------+ -읽기 배리어나 데이터 의존성 배리어를 두번째 로드 직전에 놓는다면: +읽기 배리어나 주소 의존성 배리어를 두번째 로드 직전에 놓는다면: CPU 1 CPU 2 ======================= ======================= @@ -1501,8 +1510,6 @@ u 로의 스토어를 cpu1() 의 v 로부터의 로드 뒤에 일어난 것으 (*) CPU 메모리 배리어. - (*) MMIO 쓰기 배리어. - 컴파일러 배리어 --------------- @@ -1790,21 +1797,20 @@ READ_ONCE(jiffies) 라고 할 필요가 없습니다. READ_ONCE() 와 WRITE_ONC CPU 메모리 배리어 ----------------- -리눅스 커널은 다음의 여덟개 기본 CPU 메모리 배리어를 가지고 있습니다: +리눅스 커널은 다음의 일곱개 기본 CPU 메모리 배리어를 가지고 있습니다: TYPE MANDATORY SMP CONDITIONAL - =============== ======================= =========================== + =============== ======================= =============== 범용 mb() smp_mb() 쓰기 wmb() smp_wmb() 읽기 rmb() smp_rmb() - 데이터 의존성 READ_ONCE() + 주소 의존성 READ_ONCE() -데이터 의존성 배리어를 제외한 모든 메모리 배리어는 컴파일러 배리어를 -포함합니다. 데이터 의존성은 컴파일러에의 추가적인 순서 보장을 포함하지 -않습니다. +주소 의존성 배리어를 제외한 모든 메모리 배리어는 컴파일러 배리어를 포함합니다. +주소 의존성은 컴파일러에의 추가적인 순서 보장을 포함하지 않습니다. -방백: 데이터 의존성이 있는 경우, 컴파일러는 해당 로드를 올바른 순서로 일으킬 +방백: 주소 의존성이 있는 경우, 컴파일러는 해당 로드를 올바른 순서로 일으킬 것으로 (예: `a[b]` 는 a[b] 를 로드 하기 전에 b 의 값을 먼저 로드한다) 기대되지만, C 언어 사양에는 컴파일러가 b 의 값을 추측 (예: 1 과 같음) 해서 b 로드 전에 a 로드를 하는 코드 (예: tmp = a[1]; if (b != 1) tmp = a[b]; ) 를 @@ -1842,12 +1848,15 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 (*) smp_mb__before_atomic(); (*) smp_mb__after_atomic(); - 이것들은 값을 리턴하지 않는 (더하기, 빼기, 증가, 감소와 같은) 어토믹 - 함수들을 위한, 특히 그것들이 레퍼런스 카운팅에 사용될 때를 위한 - 함수들입니다. 이 함수들은 메모리 배리어를 내포하고 있지는 않습니다. + 이것들은 메모리 배리어를 내포하지 않는 어토믹 RMW 함수를 사용하지만 코드에 + 메모리 배리어가 필요한 경우를 위한 것들입니다. 메모리 배리어를 내포하지 + 않는 어토믹 RMW 함수들의 예로는 더하기, 빼기, (실패한) 조건적 + 오퍼레이션들, _relaxed 함수들이 있으며, atomic_read 나 atomic_set 은 이에 + 해당되지 않습니다. 메모리 배리어가 필요해지는 흔한 예로는 어토믹 + 오퍼레이션을 사용해 레퍼런스 카운트를 수정하는 경우를 들 수 있습니다. - 이것들은 값을 리턴하지 않으며 어토믹한 (set_bit 과 clear_bit 같은) 비트 - 연산에도 사용될 수 있습니다. + 이것들은 또한 (set_bit 과 clear_bit 같은) 메모리 배리어를 내포하지 않는 + 어토믹 RMW bitop 함수들을 위해서도 사용될 수 있습니다. 한 예로, 객체 하나를 무효한 것으로 표시하고 그 객체의 레퍼런스 카운트를 감소시키는 다음 코드를 보세요: @@ -1865,6 +1874,7 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 (*) dma_wmb(); (*) dma_rmb(); + (*) dma_mb(); 이것들은 CPU 와 DMA 가능한 디바이스에서 모두 액세스 가능한 공유 메모리의 읽기, 쓰기 작업들의 순서를 보장하기 위해 consistent memory 에서 사용하기 @@ -1895,17 +1905,39 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 dma_rmb() 는 디스크립터로부터 데이터를 읽어오기 전에 디바이스가 소유권을 내려놓았을 것을 보장하고, dma_wmb() 는 디바이스가 자신이 소유권을 다시 - 가졌음을 보기 전에 디스크립터에 데이터가 쓰였을 것을 보장합니다. 참고로, - writel() 을 사용하면 캐시 일관성이 있는 메모리 (cache coherent memory) - 쓰기가 MMIO 영역에의 쓰기 전에 완료되었을 것을 보장하므로 writel() 앞에 - wmb() 를 실행할 필요가 없음을 알아두시기 바랍니다. writel() 보다 비용이 - 저렴한 writel_relaxed() 는 이런 보장을 제공하지 않으므로 여기선 사용되지 - 않아야 합니다. + 가졌음을 보기 전에 디스크립터에 데이터가 쓰였을 것을 보장합니다. dma_mb() + 는 dma_rmb() 와 dma_wmb() 를 모두 내포합니다. 참고로, writel() 을 + 사용하면 캐시 일관성이 있는 메모리 (cache coherent memory) 쓰기가 MMIO + 영역에의 쓰기 전에 완료되었을 것을 보장하므로 writel() 앞에 wmb() 를 + 실행할 필요가 없음을 알아두시기 바랍니다. writel() 보다 비용이 저렴한 + writel_relaxed() 는 이런 보장을 제공하지 않으므로 여기선 사용되지 않아야 + 합니다. writel_relaxed() 와 같은 완화된 I/O 접근자들에 대한 자세한 내용을 위해서는 "커널 I/O 배리어의 효과" 섹션을, consistent memory 에 대한 자세한 내용을 - 위해선 Documentation/DMA-API.txt 문서를 참고하세요. + 위해선 Documentation/core-api/dma-api.rst 문서를 참고하세요. + + (*) pmem_wmb(); + + 이것은 persistent memory 를 위한 것으로, persistent 저장소에 가해진 변경 + 사항이 플랫폼 연속성 도메인에 도달했을 것을 보장하기 위한 것입니다. + + 예를 들어, 임시적이지 않은 pmem 영역으로의 쓰기 후, 우리는 쓰기가 플랫폼 + 연속성 도메인에 도달했을 것을 보장하기 위해 pmem_wmb() 를 사용합니다. + 이는 쓰기가 뒤따르는 instruction 들이 유발하는 어떠한 데이터 액세스나 + 데이터 전송의 시작 전에 persistent 저장소를 업데이트 했을 것을 보장합니다. + 이는 wmb() 에 의해 이뤄지는 순서 규칙을 포함합니다. + Persistent memory 에서의 로드를 위해선 현재의 읽기 메모리 배리어로도 읽기 + 순서를 보장하는데 충분합니다. + + (*) io_stop_wc(); + + 쓰기와 결합된 특성을 갖는 메모리 액세스의 경우 (예: ioremap_wc() 에 의해 + 리턴되는 것들), CPU 는 앞의 액세스들이 뒤따르는 것들과 병합되게끔 기다릴 + 수 있습니다. io_stop_wc() 는 그런 기다림이 성능에 영향을 끼칠 수 있을 때, + 이 매크로 앞의 쓰기-결합된 메모리 액세스들이 매크로 뒤의 것들과 병합되는 + 것을 방지하기 위해 사용될 수 있습니다. ========================= 암묵적 커널 메모리 배리어 @@ -2413,7 +2445,7 @@ _않습니다_. 알고 있는, - inb() 나 writel() 과 같은 - 적절한 액세스 루틴을 통해 이루어져야만 합니다. 이것들은 대부분의 경우에는 명시적 메모리 배리어 와 함께 사용될 필요가 없습니다만, 완화된 메모리 액세스 속성으로 I/O 메모리 윈도우로의 참조를 위해 -액세스 함수가 사용된다면 순서를 강제하기 위해 _madatory_ 메모리 배리어가 +액세스 함수가 사용된다면 순서를 강제하기 위해 _mandatory_ 메모리 배리어가 필요합니다. 더 많은 정보를 위해선 Documentation/driver-api/device-io.rst 를 참고하십시오. @@ -2528,7 +2560,7 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서 보장을 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay() 루프 (예:앞의 2-5 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O - 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의해 + 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의한 같은 주변장치로의 액세스에는 순서가 맞춰질 것이 보장됩니다. (*) readsX(), writesX(): @@ -2661,144 +2693,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면 수도 있습니다. -캐시 일관성 ------------ - -하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로 -기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서 -만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른 -CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다. - - -두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를, -CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해 -봅시다: - - : - : +--------+ - : +---------+ | | - +--------+ : +--->| Cache A |<------->| | - | | : | +---------+ | | - | CPU 1 |<---+ | | - | | : | +---------+ | | - +--------+ : +--->| Cache B |<------->| | - : +---------+ | | - : | Memory | - : +---------+ | System | - +--------+ : +--->| Cache C |<------->| | - | | : | +---------+ | | - | CPU 2 |<---+ | | - | | : | +---------+ | | - +--------+ : +--->| Cache D |<------->| | - : +---------+ | | - : +--------+ - : - -이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다: - - (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음; - - (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음; - - (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을 - 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에 - 액세스 하기 위해 버스를 사용할 수 있음; - - (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에 - 적용되어야 할 오퍼레이션들의 큐를 가짐; - - (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는 - 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다 - 할지라도 그러함. - -이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에 -요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기 -배리어를 사용하는 상황을 상상해 봅시다: - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - u == 0, v == 1 and p == &u, q == &u - v = 2; - smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을 - 분명히 함 - <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함 - p = &v; - <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함 - -여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로 -시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을 -읽으려 하는 상황을 생각해 봅시다: - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - ... - q = p; - x = *q; - -위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU -의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의 -업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에 -업데이트 되어버렸을 수 있기 때문입니다. - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - u == 0, v == 1 and p == &u, q == &u - v = 2; - smp_wmb(); - <A:modify v=2> <C:busy> - <C:queue v=2> - p = &v; q = p; - <D:request p> - <B:modify p=&v> <D:commit p=&v> - <D:read p> - x = *q; - <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음 - <C:unbusy> - <C:commit v=2> - -기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만, -별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할 -것이라는 보장이 없습니다. - - -여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들 -사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로 -그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를 -처리하도록 강제하게 됩니다. - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - u == 0, v == 1 and p == &u, q == &u - v = 2; - smp_wmb(); - <A:modify v=2> <C:busy> - <C:queue v=2> - p = &v; q = p; - <D:request p> - <B:modify p=&v> <D:commit p=&v> - <D:read p> - smp_read_barrier_depends() - <C:unbusy> - <C:commit v=2> - x = *q; - <C:read *q> 캐시에 업데이트 된 v 를 읽음 - - -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은 -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기 -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기 -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건 -아니기 때문에 이점에 의존해선 안됩니다. - -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리 -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장 -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로 -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에 -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15 -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는 -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다. - - 캐시 일관성 VS DMA ------------------ @@ -2954,15 +2848,13 @@ ld.acq 와 stl.rel 인스트럭션을 각각 만들어 내도록 합니다. DEC Alpha CPU 는 가장 완화된 메모리 순서의 CPU 중 하나입니다. 뿐만 아니라, Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서, 의미적으로 관계되어 있는 두개의 캐시 라인이 서로 다른 시간에 업데이트 되는게 가능합니다. -이게 데이터 의존성 배리어가 정말 필요해지는 부분인데, 데이터 의존성 배리어는 -메모리 일관성 시스템과 함께 두개의 캐시를 동기화 시켜서, 포인터 변경과 새로운 -데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다. +이게 주소 의존성 배리어가 정말 필요해지는 부분인데, 주소 의존성 배리어는 메모리 +일관성 시스템과 함께 두개의 캐시를 동기화 시켜서, 포인터 변경과 새로운 데이터의 +발견을 올바른 순서로 일어나게 하기 때문입니다. 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15 -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서 -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다. - -위의 "캐시 일관성" 서브섹션을 참고하세요. +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의 +Alpha 의 영향력이 크게 줄어들었습니다. 가상 머신 게스트 |