diff options
author | SeongJae Park <sj38.park@gmail.com> | 2017-09-06 17:25:30 +0900 |
---|---|---|
committer | Jonathan Corbet <corbet@lwn.net> | 2017-09-08 10:10:46 -0600 |
commit | 53e31538165790200443e74c797960944fe20054 (patch) | |
tree | d905e5bf16de4dfc751ac7ef2c8a771a18974a96 /Documentation/translations | |
parent | 54d6d73f50966751d346a4beb2b7892e793ad649 (diff) | |
download | linux-53e31538165790200443e74c797960944fe20054.tar.gz linux-53e31538165790200443e74c797960944fe20054.tar.bz2 linux-53e31538165790200443e74c797960944fe20054.zip |
kokr/doc: Update memory-barriers.txt for read-to-write dependencies
This commit applies upstream change, commit 66ce3a4dcb9f ("doc: Update
memory-barriers.txt for read-to-write dependencies") to Korean
translation.
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/translations')
-rw-r--r-- | Documentation/translations/ko_KR/memory-barriers.txt | 38 |
1 files changed, 22 insertions, 16 deletions
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index bc80fc0e210f..bc0be1d3053f 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -617,7 +617,22 @@ RELEASE 부류의 것들도 존재합니다. 로드와 스토어를 모두 수 이 변경은 앞의 처음 두가지 결과 중 하나만이 발생할 수 있고, 세번째의 결과는 발생할 수 없도록 합니다. -데이터 의존성 배리어는 의존적 쓰기에 대해서도 순서를 잡아줍니다: + +[!] 이 상당히 반직관적인 상황은 분리된 캐시를 가지는 기계들에서 가장 잘 +발생하는데, 예를 들면 한 캐시 뱅크는 짝수 번호의 캐시 라인들을 처리하고, 다른 +뱅크는 홀수 번호의 캐시 라인들을 처리하는 경우임을 알아두시기 바랍니다. 포인터 +P 는 짝수 번호 캐시 라인에 저장되어 있고, 변수 B 는 홀수 번호 캐시 라인에 +저장되어 있을 수 있습니다. 여기서 값을 읽어오는 CPU 의 캐시의 홀수 번호 처리 +뱅크는 열심히 일감을 처리중인 반면 홀수 번호 처리 뱅크는 할 일 없이 한가한 +중이라면 포인터 P (&B) 의 새로운 값과 변수 B 의 기존 값 (2) 를 볼 수 있습니다. + + +의존적 쓰기들의 순서를 맞추는데에는 데이터 의존성 배리어가 필요치 않은데, 이는 +리눅스 커널이 지원하는 CPU 들은 (1) 쓰기가 정말로 일어날지, (2) 쓰기가 어디에 +이루어질지, 그리고 (3) 쓰여질 값을 확실히 알기 전까지는 쓰기를 수행하지 않기 +때문입니다. 하지만 "컨트롤 의존성" 섹션과 +Documentation/RCU/rcu_dereference.txt 파일을 주의 깊게 읽어 주시기 바랍니다: +컴파일러는 매우 창의적인 많은 방법으로 종속성을 깰 수 있습니다. CPU 1 CPU 2 =============== =============== @@ -626,28 +641,19 @@ RELEASE 부류의 것들도 존재합니다. 로드와 스토어를 모두 수 <쓰기 배리어> WRITE_ONCE(P, &B); Q = READ_ONCE(P); - <데이터 의존성 배리어> - *Q = 5; + WRITE_ONCE(*Q, 5); -이 데이터 의존성 배리어는 Q 로의 읽기가 *Q 로의 스토어와 순서를 맞추게 -해줍니다. 이는 다음과 같은 결과를 막습니다: +따라서, Q 로의 읽기와 *Q 로의 쓰기 사이에는 데이터 종속성 배리어가 필요치 +않습니다. 달리 말하면, 데이터 종속성 배리어가 없더라도 다음 결과는 생기지 +않습니다: (Q == &B) && (B == 4) 이런 패턴은 드물게 사용되어야 함을 알아 두시기 바랍니다. 무엇보다도, 의존성 순서 규칙의 의도는 쓰기 작업을 -예방- 해서 그로 인해 발생하는 비싼 캐시 미스도 없애려는 것입니다. 이 패턴은 드물게 발생하는 에러 조건 같은것들을 기록하는데 -사용될 수 있고, 이렇게 배리어를 사용해 순서를 지키게 함으로써 그런 기록이 -사라지는 것을 막습니다. - - -[!] 상당히 비직관적인 이 상황은 분리된 캐시를 가진 기계, 예를 들어 한 캐시 -뱅크가 짝수번 캐시 라인을 처리하고 다른 뱅크는 홀수번 캐시 라인을 처리하는 기계 -등에서 가장 잘 발생합니다. 포인터 P 는 홀수 번호의 캐시 라인에 있고, 변수 B 는 -짝수 번호 캐시 라인에 있다고 생각해 봅시다. 그런 상태에서 읽기 작업을 하는 CPU -의 짝수번 뱅크는 할 일이 쌓여 매우 바쁘지만 홀수번 뱅크는 할 일이 없어 아무 -일도 하지 않고 있었다면, 포인터 P 는 새 값 (&B) 을, 그리고 변수 B 는 옛날 값 -(2) 을 가지고 있는 상태가 보여질 수도 있습니다. +사용될 수 있으며, CPU의 자연적인 순서 보장이 그런 기록들을 사라지지 않게 +해줍니다. 데이터 의존성 배리어는 매우 중요한데, 예를 들어 RCU 시스템에서 그렇습니다. |