From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: [PATCH 10/18] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends() Date: Tue, 30 Jun 2020 18:37:26 +0100 Message-ID: <20200630173734.14057-11-will@kernel.org> References: <20200630173734.14057-1-will@kernel.org> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593538706; bh=MXGdmzGxV4dcURGH89wsFnnGgTyB+YmHiX7MrSEBkT8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Dprmmb/MZyqEarIfSctWj4BKy2ESs/GR50yOC716AdiRtob2qZv6kmXmTm3OkhJSI PpoV03qqsnutU1BpKbFIF/TOjhGhmjpPEtEUVOEneRx8YxPeQl9rPG67FkeSf3BAce BLmwFuNLpi4vQJMQgFPioTA3llzjzWgB5CzwvmsQ= In-Reply-To: <20200630173734.14057-1-will@kernel.org> Sender: linux-alpha-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8" To: linux-kernel@vger.kernel.org Cc: Will Deacon , Sami Tolvanen , Nick Desaulniers , Kees Cook , Marco Elver , "Paul E. McKenney" , Josh Triplett , Matt Turner , Ivan Kokshaysky , Richard Henderson , Peter Zijlstra , Alan Stern , "Michael S. Tsirkin" , Jason Wang , Arnd Bergmann , Boqun Feng , Catalin Marinas , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-alpha@vger.kernel.org, v From: SeongJae Park This commit translates commit ("Documentation/barriers: Remove references to [smp_]read_barrier_depends()") into Korean. Signed-off-by: SeongJae Park Reviewed-by: Yunjae Lee Signed-off-by: Will Deacon --- .../translations/ko_KR/memory-barriers.txt | 146 +----------------- 1 file changed, 3 insertions(+), 143 deletions(-) diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 34d041d68f78..a1f772ef622c 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 데이터 의존성 배리어 (역사적) ----------------------------- -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에 +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다. 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성 @@ -2664,144 +2664,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 의 변경 전에 보일 것을 - 분명히 함 - v 는 이제 캐시 A 에 독점적으로 존재함 - 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(); - - - p = &v; q = p; - - - - x = *q; - 캐시에 업데이트 되기 전의 v 를 읽음 - - - -기본적으로, 두개의 캐시라인 모두 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(); - - - p = &v; q = p; - - - - smp_read_barrier_depends() - - - x = *q; - 캐시에 업데이트 된 v 를 읽음 - - -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은 -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기 -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기 -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건 -아니기 때문에 이점에 의존해선 안됩니다. - -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리 -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장 -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로 -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에 -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15 -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는 -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다. - - 캐시 일관성 VS DMA ------------------ @@ -2962,10 +2824,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다. 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15 -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서 -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다. - -위의 "캐시 일관성" 서브섹션을 참고하세요. +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의 +Alpha 의 영향력이 크게 줄어들었습니다. 가상 머신 게스트 -- 2.27.0.212.ge8ba1cc988-goog From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: [PATCH 10/18] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends() Date: Tue, 30 Jun 2020 18:37:26 +0100 Message-ID: <20200630173734.14057-11-will@kernel.org> References: <20200630173734.14057-1-will@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20200630173734.14057-1-will@kernel.org> Sender: linux-alpha-owner@vger.kernel.org To: linux-kernel@vger.kernel.org Cc: Will Deacon , Sami Tolvanen , Nick Desaulniers , Kees Cook , Marco Elver , "Paul E. McKenney" , Josh Triplett , Matt Turner , Ivan Kokshaysky , Richard Henderson , Peter Zijlstra , Alan Stern , "Michael S. Tsirkin" , Jason Wang , Arnd Bergmann , Boqun Feng , Catalin Marinas , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-alpha@vger.kernel.orgv List-Id: virtualization@lists.linuxfoundation.org From: SeongJae Park This commit translates commit ("Documentation/barriers: Remove references to [smp_]read_barrier_depends()") into Korean. Signed-off-by: SeongJae Park Reviewed-by: Yunjae Lee Signed-off-by: Will Deacon --- .../translations/ko_KR/memory-barriers.txt | 146 +----------------- 1 file changed, 3 insertions(+), 143 deletions(-) diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 34d041d68f78..a1f772ef622c 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 데이터 의존성 배리어 (역사적) ----------------------------- -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에 +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다. 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성 @@ -2664,144 +2664,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 의 변경 전에 보일 것을 - 분명히 함 - v 는 이제 캐시 A 에 독점적으로 존재함 - 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(); - - - p = &v; q = p; - - - - x = *q; - 캐시에 업데이트 되기 전의 v 를 읽음 - - - -기본적으로, 두개의 캐시라인 모두 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(); - - - p = &v; q = p; - - - - smp_read_barrier_depends() - - - x = *q; - 캐시에 업데이트 된 v 를 읽음 - - -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은 -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기 -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기 -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건 -아니기 때문에 이점에 의존해선 안됩니다. - -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리 -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장 -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로 -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에 -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15 -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는 -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다. - - 캐시 일관성 VS DMA ------------------ @@ -2962,10 +2824,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다. 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15 -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서 -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다. - -위의 "캐시 일관성" 서브섹션을 참고하세요. +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의 +Alpha 의 영향력이 크게 줄어들었습니다. 가상 머신 게스트 -- 2.27.0.212.ge8ba1cc988-goog From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66C44C433DF for ; Tue, 30 Jun 2020 17:41:14 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3035920775 for ; Tue, 30 Jun 2020 17:41:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HCkwLEVd"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Dprmmb/M" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3035920775 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z+Xgxygyih9tEFAQKBnYDrQ34INlv1yllUdrVwWeP5M=; b=HCkwLEVd7KPXZBK1uq4ULSm28 GbevGYUzykK/hx11j9IHiZaAfKD10WQUyM7sKuoeptGWIeR2p7Ziuv9hW1x6Az5vr37JLGtds1uWR BOcKMFO3EkhYgW0Wto8bJNpenYOK+2x6ZLxpKHJ4ApqfoA44IOAkrgObkoeVOdToXdIRRG4NOzWTC Wr8k6NtyfeppyJEcJ/MOfwyuRSSVlqg9HBc1KQ1u+HBsOjH7ixjbCzhbRLK4buWazYWKRZY61cppV gBSd1gWve9AxXbdwEVNw9068uzsTPG7grsu0lslrmprUMsCwujXxyNioOT9Hp7adLEKx7x9OxB0s/ tohfzxMSA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqKE7-0001jt-IX; Tue, 30 Jun 2020 17:39:23 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqKDC-0001Ht-Vj for linux-arm-kernel@lists.infradead.org; Tue, 30 Jun 2020 17:38:31 +0000 Received: from localhost.localdomain (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1812020774; Tue, 30 Jun 2020 17:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593538706; bh=MXGdmzGxV4dcURGH89wsFnnGgTyB+YmHiX7MrSEBkT8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Dprmmb/MZyqEarIfSctWj4BKy2ESs/GR50yOC716AdiRtob2qZv6kmXmTm3OkhJSI PpoV03qqsnutU1BpKbFIF/TOjhGhmjpPEtEUVOEneRx8YxPeQl9rPG67FkeSf3BAce BLmwFuNLpi4vQJMQgFPioTA3llzjzWgB5CzwvmsQ= From: Will Deacon To: linux-kernel@vger.kernel.org Subject: [PATCH 10/18] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends() Date: Tue, 30 Jun 2020 18:37:26 +0100 Message-Id: <20200630173734.14057-11-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200630173734.14057-1-will@kernel.org> References: <20200630173734.14057-1-will@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200630_133827_490203_52970EDB X-CRM114-Status: UNSURE ( 9.00 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "Michael S. Tsirkin" , Peter Zijlstra , Catalin Marinas , Jason Wang , SeongJae Park , virtualization@lists.linux-foundation.org, Will Deacon , Arnd Bergmann , Yunjae Lee , Alan Stern , Sami Tolvanen , Matt Turner , kernel-team@android.com, Marco Elver , Kees Cook , "Paul E. McKenney" , Boqun Feng , Josh Triplett , SeongJae Park , Ivan Kokshaysky , linux-arm-kernel@lists.infradead.org, Richard Henderson , Nick Desaulniers , linux-alpha@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org RnJvbTogU2VvbmdKYWUgUGFyayA8c2ozOC5wYXJrQGdtYWlsLmNvbT4KClRoaXMgY29tbWl0IHRy YW5zbGF0ZXMgY29tbWl0ICgiRG9jdW1lbnRhdGlvbi9iYXJyaWVyczogUmVtb3ZlIHJlZmVyZW5j ZXMgdG8KW3NtcF9dcmVhZF9iYXJyaWVyX2RlcGVuZHMoKSIpIGludG8gS29yZWFuLgoKU2lnbmVk LW9mZi1ieTogU2VvbmdKYWUgUGFyayA8c2pwYXJrQGFtYXpvbi5kZT4KUmV2aWV3ZWQtYnk6IFl1 bmphZSBMZWUgPGx5ajc2OTRAZ21haWwuY29tPgpTaWduZWQtb2ZmLWJ5OiBXaWxsIERlYWNvbiA8 d2lsbEBrZXJuZWwub3JnPgotLS0KIC4uLi90cmFuc2xhdGlvbnMva29fS1IvbWVtb3J5LWJhcnJp ZXJzLnR4dCAgICB8IDE0NiArLS0tLS0tLS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAzIGlu c2VydGlvbnMoKyksIDE0MyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9u L3RyYW5zbGF0aW9ucy9rb19LUi9tZW1vcnktYmFycmllcnMudHh0IGIvRG9jdW1lbnRhdGlvbi90 cmFuc2xhdGlvbnMva29fS1IvbWVtb3J5LWJhcnJpZXJzLnR4dAppbmRleCAzNGQwNDFkNjhmNzgu LmExZjc3MmVmNjIyYyAxMDA2NDQKLS0tIGEvRG9jdW1lbnRhdGlvbi90cmFuc2xhdGlvbnMva29f S1IvbWVtb3J5LWJhcnJpZXJzLnR4dAorKysgYi9Eb2N1bWVudGF0aW9uL3RyYW5zbGF0aW9ucy9r b19LUi9tZW1vcnktYmFycmllcnMudHh0CkBAIC01NzcsNyArNTc3LDcgQEAgQUNRVUlSRSDripQg 7ZW064u5IOyYpO2NvOugiOydtOyFmOydmCDroZzrk5wg67aA67aE7JeQ66eMIOyggeyaqeuQmOqz oCBSRUxFQVNFIAog642w7J207YSwIOydmOyhtOyEsSDrsLDrpqzslrQgKOyXreyCrOyggSkKIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAKLeumrOuIheyKpCDsu6TrhJAgdjQuMTUg6riw 7KSA7Jy866GcLCBzbXBfcmVhZF9iYXJyaWVyX2RlcGVuZHMoKSDqsIAgUkVBRF9PTkNFKCkg7JeQ CivrpqzriIXsiqQg7Luk64SQIHY0LjE1IOq4sOykgOycvOuhnCwgc21wX21iKCkg6rCAIERFQyBB bHBoYSDsmqkgUkVBRF9PTkNFKCkg7L2U65Oc7JeQCiDstpTqsIDrkJjsl4jripTrjbAsIOydtOuK lCDsnbQg7IS57IWY7JeQIOyjvOydmOulvCDquLDsmrjsl6zslbwg7ZWY64qUIOyCrOuejOuTpOyd gCBERUMgQWxwaGEg7JWE7YKk7YWN7LOQCiDsoITsmqkg7L2U65Oc66W8IOunjOuTnOuKlCDsgqzr nozrk6Tqs7wgUkVBRF9PTkNFKCkg7J6Q7LK066W8IOunjOuTnOuKlCDsgqzrnozrk6Qg67+Q7J6E 7J2EIOydmOuvuO2VqeuLiOuLpC4KIOq3uOufsCDrtoTrk6TsnYQg7JyE7ZW0LCDqt7jrpqzqs6Ag 7Jet7IKs7JeQIOq0gOyLrCDsnojripQg67aE65Ok7J2EIOychO2VtCwg7Jes6riwIOuNsOydtO2E sCDsnZjsobTshLEKQEAgLTI2NjQsMTQ0ICsyNjY0LDYgQEAgQ1BVIOy9lOyWtOuKlCDtlITroZzq t7jrnqjsnZgg7J246rO87ISx7J20IOycoOyngOuQnOuLpOqzoOunjCDsl6zqsqjsp4Tri6TrqbQg CiDsiJjrj4Qg7J6I7Iq164uI64ukLgogCiAKLey6kOyLnCDsnbzqtIDshLEKLS0tLS0tLS0tLS0t Ci0KLe2VmOyngOunjCDsgrbsnYAg7JWe7JeQ7IScIOydtOyVvOq4sO2VnCDqsoPsspjrn7wg64uo 7Iic7ZWY7KeAIOyViuyKteuLiOuLpDog7LqQ7Iuc65Ok7J2AIOydvOq0gOyggeydvCDqsoPsnLzr oZwKLeq4sOuMgOuQmOyngOunjCwg6re4IOydvOq0gOyEseydtCDsiJzshJzsl5Drj4Qg7KCB7Jqp 65CgIOqxsOudvOuKlCDrs7TsnqXsnYAg7JeG7Iq164uI64ukLiAg7ZWcIENQVSDsl5DshJwKLeun jOuTpOyWtOynhCDrs4Dqsr0g7IKs7ZWt7J2AIOy1nOyiheyggeycvOuhnOuKlCDsi5zsiqTthZzs nZgg66qo65OgIENQVSDsl5Dqsowg67O07Jes7KeA6rKMIOuQmOyngOunjCwg64uk66W4Ci1DUFUg 65Ok7JeQ6rKM64+EIOqwmeydgCDsiJzshJzroZwg67O07J206rKMIOuQoCDqsbDrnbzripQg67O0 7J6l7J2AIOyXhuuLpOuKlCDrnLvsnoXri4jri6QuCi0KLQot65GQ6rCc7J2YIENQVSAoMSAmIDIp IOqwgCDri6zroKQg7J6I6rOgLCDqsIEgQ1BVIOyXkCDrkZDqsJzsnZgg642w7J207YSwIOy6kOyL nChDUFUgMSDsnYAgQS9CIOulvCwKLUNQVSAyIOuKlCBDL0Qg66W8IOqwluyKteuLiOuLpCnqsIAg 67OR66Cs66GcIOyXsOqysOuQmOyWtCDsnojripQg7Iuc7Iqk7YWc7J2EIOuLpOujrOuLpOqzoCDs g53qsIHtlbQKLeu0heyLnOuLpDoKLQotCSAgICAgICAgICAgIDoKLQkgICAgICAgICAgICA6ICAg ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0rCi0JICAgICAgICAgICAgOiAgICAgICst LS0tLS0tLS0rICAgICAgICAgfCAgICAgICAgfAotCSstLS0tLS0tLSsgIDogKy0tLT58IENhY2hl IEEgfDwtLS0tLS0tPnwgICAgICAgIHwKLQl8ICAgICAgICB8ICA6IHwgICAgKy0tLS0tLS0tLSsg ICAgICAgICB8ICAgICAgICB8Ci0JfCAgQ1BVIDEgfDwtLS0rICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgfAotCXwgICAgICAgIHwgIDogfCAgICArLS0tLS0tLS0tKyAgICAgICAgIHwg ICAgICAgIHwKLQkrLS0tLS0tLS0rICA6ICstLS0+fCBDYWNoZSBCIHw8LS0tLS0tLT58ICAgICAg ICB8Ci0JICAgICAgICAgICAgOiAgICAgICstLS0tLS0tLS0rICAgICAgICAgfCAgICAgICAgfAot CSAgICAgICAgICAgIDogICAgICAgICAgICAgICAgICAgICAgICAgIHwgTWVtb3J5IHwKLQkgICAg ICAgICAgICA6ICAgICAgKy0tLS0tLS0tLSsgICAgICAgICB8IFN5c3RlbSB8Ci0JKy0tLS0tLS0t KyAgOiArLS0tPnwgQ2FjaGUgQyB8PC0tLS0tLS0+fCAgICAgICAgfAotCXwgICAgICAgIHwgIDog fCAgICArLS0tLS0tLS0tKyAgICAgICAgIHwgICAgICAgIHwKLQl8ICBDUFUgMiB8PC0tLSsgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8Ci0JfCAgICAgICAgfCAgOiB8ICAgICstLS0t LS0tLS0rICAgICAgICAgfCAgICAgICAgfAotCSstLS0tLS0tLSsgIDogKy0tLT58IENhY2hlIEQg fDwtLS0tLS0tPnwgICAgICAgIHwKLQkgICAgICAgICAgICA6ICAgICAgKy0tLS0tLS0tLSsgICAg ICAgICB8ICAgICAgICB8Ci0JICAgICAgICAgICAgOiAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tKwotCSAgICAgICAgICAgIDoKLQot7J20IOyLnOyKpO2FnOydtCDri6TsnYzqs7wg 6rCZ7J2AIO2KueyEseydhCDqsJbripTri6Qg7IOd6rCB7ZW0IOu0heyLnOuLpDoKLQotICgqKSDt mYDsiJjrsogg7LqQ7Iuc65287J247J2AIOy6kOyLnCBBLCDsupDsi5wgQyDrmJDripQg66mU66qo 66as7JeQIOychOy5mO2VoCDsiJgg7J6I7J2MOwotCi0gKCopIOynneyImOuyiCDsupDsi5zrnbzs nbjsnYAg7LqQ7IucIEIsIOy6kOyLnCBEIOuYkOuKlCDrqZTrqqjrpqzsl5Ag7JyE7LmY7ZWgIOyI mCDsnojsnYw7Ci0KLSAoKikgQ1BVIOy9lOyWtOqwgCDtlZzqsJzsnZgg7LqQ7Iuc7JeQIOygkeq3 vO2VmOuKlCDrj5nslYgsIOuLpOuluCDsupDsi5zripQgLSDrjZTti7Ag7LqQ7Iuc65287J247J2E Ci0gICAgIOuplOuqqOumrOyXkCDrgrTrpqzqsbDrgpgg7LaU7Lih7ISxIOuhnOuTnOulvCDtlZjq sbDrgpgg7ZWY6riwIOychO2VtCAtIOyLnOyKpO2FnOydmCDri6Trpbgg67aA67aE7JeQCi0gICAg IOyVoeyEuOyKpCDtlZjquLAg7JyE7ZW0IOuyhOyKpOulvCDsgqzsmqntlaAg7IiYIOyeiOydjDsK LQotICgqKSDqsIEg7LqQ7Iuc64qUIOyLnOyKpO2FnOydmCDrgpjrqLjsp4Ag67aA67aE65Ok6rO8 IOydvOq0gOyEseydhCDrp57stpTquLAg7JyE7ZW0IO2VtOuLuSDsupDsi5zsl5AKLSAgICAg7KCB 7Jqp65CY7Ja07JW8IO2VoCDsmKTtjbzroIjsnbTshZjrk6TsnZgg7YGQ66W8IOqwgOynkDsKLQot ICgqKSDsnbQg7J286rSA7ISxIO2BkOuKlCDsupDsi5zsl5Ag7J2066+4IOyhtOyerO2VmOuKlCDr nbzsnbjsl5Ag6rCA7ZW07KeA64qUIO2PieuylO2VnCDroZzrk5zsl5Ag7J2Y7ZW07ISc64qUCi0g ICAgIOu5hOybjOyngOyngCDslYrripTrjbAsIO2BkOydmCDsmKTtjbzroIjsnbTshZjrk6TsnbQg 7J20IOuhnOuTnOydmCDqsrDqs7zsl5Ag7JiB7Zal7J2EIOuBvOy5oCDsiJgg7J6I64ukCi0gICAg IO2VoOyngOudvOuPhCDqt7jrn6ztlaguCi0KLeydtOygnCwg7LKr67KI7Ke4IENQVSDsl5DshJwg 65GQ6rCc7J2YIOyTsOq4sCDsmKTtjbzroIjsnbTshZjsnYQg66eM65Oc64qU642wLCDtlbTri7kg Q1BVIOydmCDsupDsi5zsl5AKLeyalOyyreuQnCDsiJzshJzroZwg7Jik7Y2866CI7J207IWY7J20 IOuPhOuLrOuQqOydhCDrs7TsnqXtlZjquLAg7JyE7ZW0IOuRkCDsmKTtjbzroIjsnbTshZgg7IKs 7J207JeQIOyTsOq4sAot67Cw66as7Ja066W8IOyCrOyaqe2VmOuKlCDsg4HtmansnYQg7IOB7IOB 7ZW0IOu0heyLnOuLpDoKLQotCUNQVSAxCQlDUFUgMgkJQ09NTUVOVAotCT09PT09PT09PT09PT09 PQk9PT09PT09PT09PT09PT0JPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0JCQkJCXUgPT0gMCwgdiA9PSAxIGFuZCBwID09ICZ1LCBxID09ICZ1Ci0JdiA9IDI7Ci0Jc21w X3dtYigpOwkJCXYg7J2YIOuzgOqyveydtCBwIOydmCDrs4Dqsr0g7KCE7JeQIOuztOydvCDqsoPs nYQKLQkJCQkJIOu2hOuqhe2eiCDtlagKLQk8QTptb2RpZnkgdj0yPgkJCXYg64qUIOydtOygnCDs upDsi5wgQSDsl5Ag64+F7KCQ7KCB7Jy866GcIOyhtOyerO2VqAotCXAgPSAmdjsKLQk8Qjptb2Rp ZnkgcD0mdj4JCQlwIOuKlCDsnbTsoJwg7LqQ7IucIEIg7JeQIOuPheygkOyggeycvOuhnCDsobTs nqztlagKLQot7Jes6riw7ISc7J2YIOyTsOq4sCDrqZTrqqjrpqwg67Cw66as7Ja064qUIENQVSAx IOydmCDsupDsi5zqsIAg7Jis67CU66W4IOyInOyEnOuhnCDsl4XrjbDsnbTtirgg65CcIOqyg+yc vOuhnAot7Iuc7Iqk7YWc7J2YIOuLpOuluCBDUFUg65Ok7J20IOyduOyngO2VmOqyjCDrp4zrk63r i4jri6QuICDtlZjsp4Drp4wsIOydtOygnCDrkZDrsojsp7ggQ1BVIOqwgCDqt7gg6rCS65Ok7J2E Ci3snb3snLzroKQg7ZWY64qUIOyDge2ZqeydhCDsg53qsIHtlbQg67SF7Iuc64ukOgotCi0JQ1BV IDEJCUNQVSAyCQlDT01NRU5UCi0JPT09PT09PT09PT09PT09CT09PT09PT09PT09PT09PQk9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLQkuLi4KLQkJCXEgPSBwOwotCQkJ eCA9ICpxOwotCi3snITsnZgg65GQ6rCc7J2YIOydveq4sCDsmKTtjbzroIjsnbTshZjsnYAg7JiI 7IOB65CcIOyInOyEnOuhnCDsnbzslrTrgpjsp4Ag66q77ZWgIOyImCDsnojripTrjbAsIOuRkOuy iOynuCBDUFUKLeydmCDtlZwg7LqQ7Iuc7JeQIOuLpOuluCDsupDsi5wg7J2067Kk7Yq46rCAIOuw nOyDne2VtCB2IOulvCDri7Tqs6Ag7J6I64qUIOy6kOyLnOudvOyduOydmCDtlbTri7kg7LqQ7Iuc 7JeQ7J2YCi3sl4XrjbDsnbTtirjqsIAg7KeA7Jew65CY64qUIOyCrOydtCwgcCDrpbwg64u06rOg IOyeiOuKlCDsupDsi5zrnbzsnbjsnYAg65GQ67KI7Ke4IENQVSDsnZgg64uk66W4IOy6kOyLnOyX kAot7JeF642w7J207Yq4IOuQmOyWtOuyhOuguOydhCDsiJgg7J6I6riwIOuVjOusuOyeheuLiOuL pC4KLQotCUNQVSAxCQlDUFUgMgkJQ09NTUVOVAotCT09PT09PT09PT09PT09PQk9PT09PT09PT09 PT09PT0JPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0JCQkJCXUgPT0g MCwgdiA9PSAxIGFuZCBwID09ICZ1LCBxID09ICZ1Ci0JdiA9IDI7Ci0Jc21wX3dtYigpOwotCTxB Om1vZGlmeSB2PTI+CTxDOmJ1c3k+Ci0JCQk8QzpxdWV1ZSB2PTI+Ci0JcCA9ICZ2OwkJcSA9IHA7 Ci0JCQk8RDpyZXF1ZXN0IHA+Ci0JPEI6bW9kaWZ5IHA9JnY+CTxEOmNvbW1pdCBwPSZ2PgotCQkJ PEQ6cmVhZCBwPgotCQkJeCA9ICpxOwotCQkJPEM6cmVhZCAqcT4J7LqQ7Iuc7JeQIOyXheuNsOyd tO2KuCDrkJjquLAg7KCE7J2YIHYg66W8IOydveydjAotCQkJPEM6dW5idXN5PgotCQkJPEM6Y29t bWl0IHY9Mj4KLQot6riw67O47KCB7Jy866GcLCDrkZDqsJzsnZgg7LqQ7Iuc65287J24IOuqqOuR kCBDUFUgMiDsl5Ag7LWc7KKF7KCB7Jy866Gc64qUIOyXheuNsOydtO2KuCDrkKAg6rKD7J207KeA 66eMLAot67OE64+E7J2YIOqwnOyehSDsl4bsnbTripQsIOyXheuNsOydtO2KuOydmCDsiJzshJzq sIAgQ1BVIDEg7JeQ7IScIOunjOuTpOyWtOynhCDsiJzshJzsmYAg64+Z7J287ZWgCi3qsoPsnbTr nbzripQg67O07J6l7J20IOyXhuyKteuLiOuLpC4KLQotCi3sl6zquLDsl5Ag6rCc7J6F7ZWY6riw IOychO2VtOyEoCwg642w7J207YSwIOydmOyhtOyEsSDrsLDrpqzslrTrgpgg7J296riwIOuwsOum rOyWtOulvCDroZzrk5wg7Jik7Y2866CI7J207IWY65OkCi3sgqzsnbTsl5Ag64Sj7Ja07JW8IO2V qeuLiOuLpCAodjQuMTUg67aA7YSw64qUIFJFQURfT05DRSgpIOunpO2BrOuhnOyXkCDsnZjtlbQg 66y07KGw6rG07KCB7Jy866GcCi3qt7jroIfqsowg65Cp64uI64ukKS4gIOydtOugh+qyjCDtlajs nLzroZzsjagg7LqQ7Iuc6rCAIOuLpOydjCDsmpTssq3snYQg7LKY66as7ZWY6riwIOyghOyXkCDs nbzqtIDshLEg7YGQ66W8Ci3sspjrpqztlZjrj4TroZ0g6rCV7KCc7ZWY6rKMIOuQqeuLiOuLpC4K LQotCUNQVSAxCQlDUFUgMgkJQ09NTUVOVAotCT09PT09PT09PT09PT09PQk9PT09PT09PT09PT09 PT0JPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0JCQkJCXUgPT0gMCwg diA9PSAxIGFuZCBwID09ICZ1LCBxID09ICZ1Ci0JdiA9IDI7Ci0Jc21wX3dtYigpOwotCTxBOm1v ZGlmeSB2PTI+CTxDOmJ1c3k+Ci0JCQk8QzpxdWV1ZSB2PTI+Ci0JcCA9ICZ2OwkJcSA9IHA7Ci0J CQk8RDpyZXF1ZXN0IHA+Ci0JPEI6bW9kaWZ5IHA9JnY+CTxEOmNvbW1pdCBwPSZ2PgotCQkJPEQ6 cmVhZCBwPgotCQkJc21wX3JlYWRfYmFycmllcl9kZXBlbmRzKCkKLQkJCTxDOnVuYnVzeT4KLQkJ CTxDOmNvbW1pdCB2PTI+Ci0JCQl4ID0gKnE7Ci0JCQk8QzpyZWFkICpxPgnsupDsi5zsl5Ag7JeF 642w7J207Yq4IOuQnCB2IOulvCDsnb3snYwKLQotCi3snbTrn7Ag67aA66WY7J2YIOusuOygnOuK lCBERUMgQWxwaGEg6rOE7Je0IO2UhOuhnOyEuOyEnOuTpOyXkOyEnCDrsJzqsqzrkKAg7IiYIOye iOuKlOuNsCwg7J2065Ok7J2ACi3rjbDsnbTthLAg67KE7Iqk66W8IOyigCDrjZQg7J6YIOyCrOya qe2VtCDshLHriqXsnYQg6rCc7ISg7ZWgIOyImCDsnojripQsIOu2hO2VoOuQnCDsupDsi5zrpbwg 6rCA7KeA6rOgIOyeiOq4sAot65WM66y47J6F64uI64ukLiAg64yA67aA67aE7J2YIENQVSDripQg 7ZWY64KY7J2YIOydveq4sCDsmKTtjbzroIjsnbTshZjsnZgg66mU66qo66asIOyVoeyEuOyKpOqw gCDri6Trpbgg7J296riwCi3smKTtjbzroIjsnbTshZjsl5Ag7J2Y7KG07KCB7J20652866m0IOuN sOydtO2EsCDsnZjsobTshLEg67Cw66as7Ja066W8IOuCtO2PrOyLnO2CteuLiOuLpOunjCwg66qo 65GQ6rCAIOq3uOufsOqxtAot7JWE64uI6riwIOuVjOusuOyXkCDsnbTsoJDsl5Ag7J2Y7KG07ZW0 7ISgIOyViOuQqeuLiOuLpC4KLQot64uk66W4IENQVSDrk6Trj4Qg67aE7ZWg65CcIOy6kOyLnOul vCDqsIDsp4Dqs6Ag7J6I7J2EIOyImCDsnojsp4Drp4wsIOq3uOufsCBDUFUg65Ok7J2AIO2Pieuy lO2VnCDrqZTrqqjrpqwKLeyVoeyEuOyKpOulvCDsnITtlbTshJzrj4Qg7J20IOu2hO2VoOuQnCDs upDsi5zrk6Qg7IKs7J207J2YIOyhsOygleydhCDtlbTslbzrp4wg7ZWp64uI64ukLiAgQWxwaGEg 64qUIOqwgOyepQot7JW97ZWcIOuplOuqqOumrCDsiJzshJwg7Iuc66eo7YuxIChzZW1hbnRpYykg 7J2EIOyEoO2Dne2VqOycvOuhnOyNqCDrqZTrqqjrpqwg67Cw66as7Ja06rCAIOuqheyLnOyggeyc vOuhnAot7IKs7Jqp65CY7KeAIOyViuyVmOydhCDrlYzsl5DripQg6re465+wIOyhsOygleydtCDt lYTsmpTtlZjsp4Ag7JWK6rKMIO2WiOycvOupsCwg7J2064qUIEFscGhhIOqwgCDri7nsi5zsl5AK LeuNlCDrhpLsnYAgQ1BVIO2BtOudvSDsho3rj4Trpbwg6rCA7KeIIOyImCDsnojqsowg7ZaI7Iq1 64uI64ukLiAg7ZWY7KeA66eMLCAo64uk7IucIOunkO2VmOqxtOuMgCwgdjQuMTUKLeydtO2bhOu2 gO2EsOuKlCkgQWxwaGEg7JWE7YKk7YWN7LOQIOyghOyaqSDsvZTrk5zsmYAgUkVBRF9PTkNFKCkg 66ek7YGs66GcIOuCtOu2gOyXkOyEnOulvCDsoJzsmbjtlZjqs6DripQKLXNtcF9yZWFkX2JhcnJp ZXJfZGVwZW5kcygpIOqwgCDsgqzsmqnrkJjsp4Ag7JWK7JWE7JW8IO2VqOydhCDslYzslYTrkZDs i5zquLAg67CU656N64uI64ukLgotCi0KIOy6kOyLnCDsnbzqtIDshLEgVlMgRE1BCiAtLS0tLS0t LS0tLS0tLS0tLS0KIApAQCAtMjk2MiwxMCArMjgyNCw4IEBAIEFscGhhIENQVSDsnZgg7J2867aA IOuyhOyghOydgCDrtoTtlaDrkJwg642w7J207YSwIOy6kOyLnOulvCDqsIDsp4Dqs6Ag7J6I7Ja0 7IScCiDrjbDsnbTthLDsnZgg67Cc6rKs7J2EIOyYrOuwlOuluCDsiJzshJzroZwg7J287Ja064KY 6rKMIO2VmOq4sCDrlYzrrLjsnoXri4jri6QuCiAKIOumrOuIheyKpCDsu6TrhJDsnZgg66mU66qo 66asIOuwsOumrOyWtCDrqqjrjbjsnYAgQWxwaGEg7JeQIOq4sOy0iO2VtOyEnCDsoJXsnZjrkJjs l4jsirXri4jri6Trp4wsIHY0LjE1Ci3rtoDthLDripQg66as64iF7IqkIOy7pOuEkOydtCBSRUFE X09OQ0UoKSDrgrTsl5Agc21wX3JlYWRfYmFycmllcl9kZXBlbmRzKCkg66W8IOy2lOqwgO2VtOyE nAotQWxwaGEg7J2YIOuplOuqqOumrCDrqqjrjbjroZzsnZgg7JiB7Zal66Cl7J20IO2BrOqyjCDs pITslrTrk6TquLQg7ZaI7Iq164uI64ukLgotCi3snITsnZggIuy6kOyLnCDsnbzqtIDshLEiIOyE nOu4jOyEueyFmOydhCDssLjqs6DtlZjshLjsmpQuCivrtoDthLDripQgQWxwaGEg7JqpIFJFQURf T05DRSgpIOy9lOuTnCDrgrTsl5Agc21wX21iKCkg6rCAIOy2lOqwgOuQmOyWtOyEnCDrqZTrqqjr pqwg66qo642466Gc7J2YCitBbHBoYSDsnZgg7JiB7Zal66Cl7J20IO2BrOqyjCDspITslrTrk6Ts l4jsirXri4jri6QuCiAKIAog6rCA7IOBIOuouOyLoCDqsozsiqTtirgKLS0gCjIuMjcuMC4yMTIu Z2U4YmExY2M5ODgtZ29vZwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxA bGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59B7DC433E0 for ; Tue, 30 Jun 2020 17:38:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1B30B20826 for ; Tue, 30 Jun 2020 17:38:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593538713; bh=MXGdmzGxV4dcURGH89wsFnnGgTyB+YmHiX7MrSEBkT8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=rYUsR739VeHflYnHVf7p2UKmUhAyeIizvUscMXBW/keh/GHepADtwPEXIcjoXMbf5 +NjWPsb+/ig3ooLJqDn6TZtbDIWVGcX1jbLbd/q7Rl1IwVKkTbL7Z8jArHDmdeJa/E Ssfn+3skckZDLwokRu+omk1g0pfwIeBuK136A4vI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390411AbgF3Rib (ORCPT ); Tue, 30 Jun 2020 13:38:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:51466 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388026AbgF3Ri1 (ORCPT ); Tue, 30 Jun 2020 13:38:27 -0400 Received: from localhost.localdomain (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1812020774; Tue, 30 Jun 2020 17:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593538706; bh=MXGdmzGxV4dcURGH89wsFnnGgTyB+YmHiX7MrSEBkT8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Dprmmb/MZyqEarIfSctWj4BKy2ESs/GR50yOC716AdiRtob2qZv6kmXmTm3OkhJSI PpoV03qqsnutU1BpKbFIF/TOjhGhmjpPEtEUVOEneRx8YxPeQl9rPG67FkeSf3BAce BLmwFuNLpi4vQJMQgFPioTA3llzjzWgB5CzwvmsQ= From: Will Deacon To: linux-kernel@vger.kernel.org Cc: Will Deacon , Sami Tolvanen , Nick Desaulniers , Kees Cook , Marco Elver , "Paul E. McKenney" , Josh Triplett , Matt Turner , Ivan Kokshaysky , Richard Henderson , Peter Zijlstra , Alan Stern , "Michael S. Tsirkin" , Jason Wang , Arnd Bergmann , Boqun Feng , Catalin Marinas , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-alpha@vger.kernel.org, virtualization@lists.linux-foundation.org, kernel-team@android.com, SeongJae Park , SeongJae Park , Yunjae Lee Subject: [PATCH 10/18] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends() Date: Tue, 30 Jun 2020 18:37:26 +0100 Message-Id: <20200630173734.14057-11-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200630173734.14057-1-will@kernel.org> References: <20200630173734.14057-1-will@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: SeongJae Park This commit translates commit ("Documentation/barriers: Remove references to [smp_]read_barrier_depends()") into Korean. Signed-off-by: SeongJae Park Reviewed-by: Yunjae Lee Signed-off-by: Will Deacon --- .../translations/ko_KR/memory-barriers.txt | 146 +----------------- 1 file changed, 3 insertions(+), 143 deletions(-) diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 34d041d68f78..a1f772ef622c 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 데이터 의존성 배리어 (역사적) ----------------------------- -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에 +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다. 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성 @@ -2664,144 +2664,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 의 변경 전에 보일 것을 - 분명히 함 - v 는 이제 캐시 A 에 독점적으로 존재함 - 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(); - - - p = &v; q = p; - - - - x = *q; - 캐시에 업데이트 되기 전의 v 를 읽음 - - - -기본적으로, 두개의 캐시라인 모두 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(); - - - p = &v; q = p; - - - - smp_read_barrier_depends() - - - x = *q; - 캐시에 업데이트 된 v 를 읽음 - - -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은 -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기 -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기 -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건 -아니기 때문에 이점에 의존해선 안됩니다. - -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리 -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장 -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로 -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에 -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15 -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는 -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다. - - 캐시 일관성 VS DMA ------------------ @@ -2962,10 +2824,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다. 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15 -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서 -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다. - -위의 "캐시 일관성" 서브섹션을 참고하세요. +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의 +Alpha 의 영향력이 크게 줄어들었습니다. 가상 머신 게스트 -- 2.27.0.212.ge8ba1cc988-goog