On Mon, Jul 04, 2016 at 08:27:08AM +0900, SeongJae Park wrote:
> +===================================
> +이 문서는
> +Documentation/memory-barriers.txt
> +의 한글 번역입니다.
> +
> +역자： 박성재 <sj38.park@xxxxxxxxx>
> +===================================
> +
> +
> + =========================
> + 리눅스 커널 메모리 배리어
> + =========================
> +
> +저자: David Howells <dhowells@xxxxxxxxxx>
> + Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> + Will Deacon <will.deacon@xxxxxxx>
> + Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> +
> +========
> +면책조항
> +========
> +
> +이 문서는 명세서가 아닙니다; 이 문서는 완벽하지 않은데, 간결성을 위해 의도된
> +부분도 있고, 의도하진 않았지만 사람에 의해 쓰였다보니 그러한 부분도 있습니다.
I will add my opinion in korean.
그러한 부분 -> 불완전한 부분
> +이 문서는 리눅스에서 제공하는 다양한 메모리 배리어들을 사용하기 위한
> +안내서입니다만 뭔가 이상하다 싶으면 (그런게 많을 겁니다) 질문을 부탁드립니다.
> +
> +다시 말하지만, 이 문서는 리눅스가 하드웨어에 기대하는 사항에 대한 명세서가
> +아닙니다.
> +
> +이 문서의 목적은 두가지입니다:
> +
> + (1) 어떤 특정 배리어에 대해 기대할 수 있는 최소한의 기능을 명세하기 위해서,
> + 그리고
> +
> + (2) 사용 가능한 배리어들에 대해 어떻게 사용해야 하는지에 대한 안내를 제공하기
> + 위해서.
> +
> +어떤 아키텍쳐는 특정한 배리어들에 대해서는 여기서 이야기하는 최소한의
> +요구사항들보다 많은 기능을 제공할 수도 있습니다만, 여기서 이야기하는
> +요구사항들을 충족하지 않는 아키텍쳐가 있다면 그 아키텍쳐가 잘못된 것이란 점을
> +주의하시기 바랍니다.
주의하시기 -> 알아두시기
> +
> +또한, 일부 배리어는 특정 아키텍쳐에서는 해당 아키텍쳐의 동작 방식으로 인해
> +명시적으로 해당 배리어의 명시적 사용이 불필요해서 no-op 이 될수도 있음에
"명시적" 이라는 단어는 한번만...
> +주의하시기 바랍니다.
주의하시기 -> 알아두시기
> +=======================
> +추상 메모리 액세스 모델
> +=======================
> +
> +다음과 같이 추상화된 시스템 모델을 생각해 봅시다:
> +
> + : :
> + : :
> + : :
> + +-------+ : +--------+ : +-------+
> + | | : | | : | |
> + | | : | | : | |
> + | CPU 1 |<----->| Memory |<----->| CPU 2 |
> + | | : | | : | |
> + | | : | | : | |
> + +-------+ : +--------+ : +-------+
> + ^ : ^ : ^
> + | : | : |
> + | : | : |
> + | : v : |
> + | : +--------+ : |
> + | : | | : |
> + | : | | : |
> + +---------->| Device |<----------+
> + : | | :
> + : | | :
> + : +--------+ :
> + : :
> +
> +각 CPU 는 메모리 액세스 오퍼레이션들을 발생시키는 프로그램을 실행합니다.
> +추상화된 CPU 모델에서 메모리 오퍼레이션들의 순서는 매우 완화되어 있고, CPU 는
> +프로그램이 인과관계를 어기지 않는 상태로 관리된다고 보일 수만 있다면 메모리
> +오퍼레이션들을 자신이 원하는 어떤 순서대로든 재배치해 실행할 수 있습니다.
영어는 긴 문장을 자주 사용하는 것 같아요. 반면에 한국어는 문장이 길어지면
읽기가 좀더 어려워 지는 것 같습니다. 필요하면 여러 문장 이상으로 분리하는
것이 좋을 것 같습니다. 이 문장도 두 문장으로 분리하는 게 더 좋지 않을까요?
> +비슷하게, 컴파일러 또한 프로그램의 정상적 동작을 해치지 않는 한도 내에서는 어떤
> +순서로든 자신이 원하는 대로 명령어들을 재배치 할 수 있습니다.
> +
> +따라서 위의 다어그램에서 한 CPU가 수행하는 메모리 오퍼레이션의 효과는
> +오퍼레이션이 CPU 와 시스템의 다른 부분들 사이의 인터페이스 (점선) 를 지나갈 때
> +시스템의 나머지 부분들에 전파됩니다.
따라서 위의 다*이*어그램에서 한 CPU가 수행하는 메오리 오퍼레이션의 결과는
오퍼레이션이 CPU와 시스템의 다른 부분들 사이의 인터페이스(점선)를 지날 때
시스템의 나머지 부분들이 인지할 수 있게 됩니다.
> +
> +
> +예를 들어, 다음의 일련의 이벤트들을 생각해 봅시다:
> +
> + CPU 1 CPU 2
> + =============== ===============
> + { A == 1; B == 2 }
> + A = 3; x = B;
> + B = 4; y = A;
> +
> +그림의 가운데 위치한 메모리 시스템에 보여지게 될 액세스들은 다음의 총 24개 서로
> +다른 조합으로 재구성될 수 있습니다:
그림 가운데에 위치한 메모리 시스템에 보여지게 되는 엑세스 조합은 (...)
> +
> + STORE A=3, STORE B=4, y=LOAD A->3, x=LOAD B->4
> + STORE A=3, STORE B=4, x=LOAD B->4, y=LOAD A->3
> + STORE A=3, y=LOAD A->3, STORE B=4, x=LOAD B->4
> + STORE A=3, y=LOAD A->3, x=LOAD B->2, STORE B=4
> + STORE A=3, x=LOAD B->2, STORE B=4, y=LOAD A->3
> + STORE A=3, x=LOAD B->2, y=LOAD A->3, STORE B=4
> + STORE B=4, STORE A=3, y=LOAD A->3, x=LOAD B->4
> + STORE B=4, ...
> + ...
> +
> +따라서 다음의 네가지 조합의 결과가 나올 수 있습니다:
(...) 조합이 나올 수 있습니다.
> +
> + x == 2, y == 1
> + x == 2, y == 3
> + x == 4, y == 1
> + x == 4, y == 3
> +
> +
> +더욱이, 한 CPU 에 의해 메모리 시스템에 행해진 스토어 오퍼레이션들은 다른 CPU 의
> +로드 오퍼레이션 들에 스토어가 행해진 순서와 다른 순서로 읽혀질 수 있습니다.
훨씬 읽기 좋아지긴 했지만, 아직도 직역을 해서 읽기 어색한 부분이이 꽤 남아
있는 것 같습니다. 수정 부탁드립니다.
(..) 한 CPU가 메모리 시스템에 반영한 스토어 오퍼레이션들은 다른 CPU에서
로드 오퍼레이션을 통해서 인지할 수 있는데, 이 때 스토어가 반영된 순서대로
보여지지 않을 수 있습니다.
> +
> +
> +예로, 아래의 일련의 이벤트들을 생각해 봅시다:
> +
> + CPU 1 CPU 2
> + =============== ===============
> + { A == 1, B == 2, C == 3, P == &A, Q == &C }
> + B = 4; Q = P;
> + P = &B D = *Q;
> +
> +D 로 읽혀지는 값은 CPU 2 에서 P 로부터 읽혀진 주소값에 의존적이기 때문에 여기엔
> +분명한 데이터 의존성이 있습니다. 이 이벤트들의 실행 결과로는 아래의 결과들이
> +모두 나타날 수 있습니다:
> +
> + (Q == &A) and (D == 1)
> + (Q == &B) and (D == 2)
> + (Q == &B) and (D == 4)
> +
> +CPU 2 는 *Q 의 로드를 요청하기 전에 P 를 Q 에 넣기 때문에 D 에 C 를 집어넣는
> +일은 없음에 주의하세요.
주의하세요 -> 알아두세요
> +
> +
> +디바이스 오퍼레이션
> +-------------------
> +
> +일부 디바이스들은 제어 인터페이스를 메모리 위치의 집합으로 제공하는데, 해당
일부 디바이스들은 제어 인터페이스가 메모리 내 일부 영역에 위치하는 데, 이때 해당
> +컨트롤 레지스터에 접근하는 순서는 매우 중요합니다. 예를 들어, 어드레스 포트
문서 전체에 걸쳐서 컨트롤 또는 제어 중에 선택해서 번역해 주세요.
> +레지스터 (A) 와 데이터 포트 레지스터 (D) 를 통해 접근되는 내부 레지스터 집합을
> +갖는 이더넷 카드를 생각해 봅시다. 내부의 5번 레지스터를 읽으려면 다음의 코드가
> +사용될 수 있을 겁니다:
(...) 읽기 위해 다음 코드가 사용될 수 있습니다:
> +
> + *A = 5;
> + x = *D;
> +
> +하지만 이건 다음의 두 조합 중 하나로 보여질 수 있을 겁니다:
(...) 있습니다:
> +
> + STORE *A = 5, x = LOAD *D
> + x = LOAD *D, STORE *A = 5
> +
> +두번째 조합은 데이터를 읽어온 _후에_ 주소를 설정하므로, 잘못된 동작을 일으킬
> +것입니다.
> +
> +
> +보장사항
> +--------
> +
> +CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니다:
> +
> + (*) 어떤 CPU 든, 의존성이 존재하는 메모리 액세스들은 해당 CPU 자신에게
> + 있어서는 해당 순서 그대로 요청됩니다. 즉, 다음에 대해서는:
요청됩니다. -> 수행됩니다.
> +
> + Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
> +
> + CPU 는 다음과 같은 메모리 오퍼레이션들을 요청합니다:
(...) 아래 메모리 오퍼레이션을 수행합니다:
> +
> + Q = LOAD P, D = LOAD *Q
> +
> + 그리고 그 순서는 항상 지켜집니다. 대부분의 시스템에서
> + smp_read_barrier_depends() 는 아무일도 안하지만 DEC Alpha 에서는
> + 명시적으로 사용되어야 합니다. 보통의 경우에는 smp_read_barrier_depends()
> + 를 직접 사용하는 대신 rcu_dereference() 같은 것들을 사용해야 함을
> + 주의하십시오.
주의하십시오 -> 알아두세요.
> +
> + (*) 특정 CPU 내에서 겹쳐서 행해지는 로드와 스토어 들은 그 CPU 안에서는 순서가
메모리 영역이 겹치는 로드와 스토어가 한 CPU 내에서 수행될 경우, 해당 CPU
내에서 보았을 때에 그 순서는 바뀌지 않습니다. (...)
> + 맞춰진 것으로 나타납니다. 즉, 다음에 대해서:
> +
> + a = READ_ONCE(*X); WRITE_ONCE(*X, b);
> +
> + CPU 는 다음의 메모리 오퍼레이션 배열만을 메모리에 요청할 것입니다:
배열? 너무 뜬금없는 단어네요..
-> 해당 CPU는 오직 다음 순서대로 메모리 오퍼레이션을 수행할 것입니다.
> +
> + a = LOAD *X, STORE *X = b
> +
> + 그리고 다음에 대해서는:
> +
> + WRITE_ONCE(*X, c); d = READ_ONCE(*X);
> +
> + CPU 는 오로지 다음의 명령만을 냅니다:
(...) 오로지 아래 순서로 수행합니다.
> +
> + STORE *X = c, d = LOAD *X
> +
> + (로드와 스토어는 겹치는 메모리 영역을 타겟으로 할 때에 겹쳐집니다).
직역보다는 의역을 사용해 주세요..
(로드와 스토어가 수행하고자 하는 메모리 영역이 겹치는 경우, 로드와 스토어가
겹친다고 말합니다.)
---
I think there are still many things literally translated. It makes it much
harder to read.
I think it's not the version with which I can add opinions line by line.
Please review all sentences line by line carefully by yourself and make it
more readable.
I hope you don't hurry and spend more time to make it done. I believe you
agree with it.
Thank you,
Byungchul
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
