2016-07-07 21:00 GMT+09:00 Byungchul Park <byungchul.park@xxxxxxx>:
> 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.
Thank you for kind and faithful review. I agree with most of your opinions and
suggestions. Most of your suggestions looks much better than mine.
However, I also have some different opinion. I want to emphasize the fact that
(1) CPUs 'issue' memory operations to memory system as they want, (2) memory
system 'executes' those operations as they want, and (3) CPUs 'perceive' the
'effects' of the operation executions as they want. I want to emphasize the
fact in document because I think most confusion about memory ordering comes
from vague understanding about the relation. To my perspective, few of your
suggestions could enhance readability but could dim the point, too. I have
appended the opinion in Korean line by line, too. So, if you do not opposed
to, I will enhance the text again while keeping the point.
>
> 그러한 부분 -> 불완전한 부분
네, 그게 더 좋을 것 같네요.
>
>> +이 문서는 리눅스에서 제공하는 다양한 메모리 배리어들을 사용하기 위한
>> +안내서입니다만 뭔가 이상하다 싶으면 (그런게 많을 겁니다) 질문을 부탁드립니다.
>> +
>> +다시 말하지만, 이 문서는 리눅스가 하드웨어에 기대하는 사항에 대한 명세서가
>> +아닙니다.
>> +
>> +이 문서의 목적은 두가지입니다:
>> +
>> + (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 자신에게
>> + 있어서는 해당 순서 그대로 요청됩니다. 즉, 다음에 대해서는:
>
> 요청됩니다. -> 수행됩니다.
CPU (또는 디바이스) 는 메모리 오퍼레이션을 메모리 시스템에 '요청'하고 메모리
시스템에 의해 '수행'된 오퍼레이션의 '결과'를 '받거나' 다른 CPU 가 요청해서
메모리 시스템에서 수행된 오퍼레이션의 영향을 받게 되는 것인데, (1) CPU 가
코드와 순서를 바꿔서 요청할 수 있고, (2) (캐시를 포함한) 메모리 시스템이 요청된
오퍼레이션들을 임의의 순서로 수행할 수 있고, (3) 메모리 시스템의 수행 결과를 각
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.
Ok, I agree with your opinion. Actually, I have reviewed all sentences line by
line for this version, too. However, it looks like it wasn't sufficient. I
will enhance it again.
>
> Thank you,
> Byungchul
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
