From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: [PATCH v3 11/19] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends() Date: Fri, 10 Jul 2020 17:51:55 +0100 Message-ID: <20200710165203.31284-12-will@kernel.org> References: <20200710165203.31284-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=1594399976; bh=41KnUwWYjh1L4ww56o0v6hGwIPLLgxOofq56d83amoQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O0jjZWL7mt0G7iW7zch92TtJ0Rj5J2tK8hjOCQCT6hUalwV6hHLRMKQ6BzYxt31kt Bp3takgf77JdKvrQ2+XZhS1O3g2rYt9m97eMu98EINHrX3BsBoDVdnG5p8vRGXZeF6 97jjEzPw3ZNRGBk2f0whnYPzbQ6d9PPFr9qBb+Qo= In-Reply-To: <20200710165203.31284-1-will@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8" To: linux-kernel@vger.kernel.org Cc: Will Deacon , Joel Fernandes , Sami Tolvanen , Nick Desaulniers , Kees Cook , Marco Elver , "Paul E. McKenney" , 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, virtualizati 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.383.g050319c2ae-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=-13.0 required=3.0 tests=BAYES_00,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 7DF80C433E2 for ; Fri, 10 Jul 2020 16:57:11 +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 387AD2078B for ; Fri, 10 Jul 2020 16:57:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RxV3B9L5"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="O0jjZWL7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 387AD2078B 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=HU5incif6ccDJkbI6G6IQft6VhDyzPOOz+xlWvBiTu8=; b=RxV3B9L5MGAUwv1gQNYZn77th +fBfkeTHjkGhbnjZGOCjZY+aV6Wm3awRiAfgXLI/9atnfLo8DnQ6QG3jyWwaHlw/uhvsnEvq/n+hU 22Cu71OidDzddRju5pb3tJbMpwBUaBWNZ9O+a1vD8zAYITuV2YF1YjunBiyKGrMwHgV7j2t1aZzkQ utUqrD+xBGnZEfjULp0uredDJp4p5eBBRmqQhFWu1nUdLKbuKx8etZmxu4xas/CsAeQbATUCM2IUp /2A41wT9wJrWq8xKVvuGz3cHMxIeNbEf3RTf7hqD/vIa0STIcVvPxsCpNAyWhNN8JXY2sYEAq3iDj rZJEpuY2Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtwIa-0006Nh-VR; Fri, 10 Jul 2020 16:54:57 +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 1jtwGf-0005YD-Fc for linux-arm-kernel@lists.infradead.org; Fri, 10 Jul 2020 16:53:02 +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 D4B2F206F4; Fri, 10 Jul 2020 16:52:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594399976; bh=41KnUwWYjh1L4ww56o0v6hGwIPLLgxOofq56d83amoQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O0jjZWL7mt0G7iW7zch92TtJ0Rj5J2tK8hjOCQCT6hUalwV6hHLRMKQ6BzYxt31kt Bp3takgf77JdKvrQ2+XZhS1O3g2rYt9m97eMu98EINHrX3BsBoDVdnG5p8vRGXZeF6 97jjEzPw3ZNRGBk2f0whnYPzbQ6d9PPFr9qBb+Qo= From: Will Deacon To: linux-kernel@vger.kernel.org Subject: [PATCH v3 11/19] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends() Date: Fri, 10 Jul 2020 17:51:55 +0100 Message-Id: <20200710165203.31284-12-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200710165203.31284-1-will@kernel.org> References: <20200710165203.31284-1-will@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200710_125257_855812_C1B4AB84 X-CRM114-Status: UNSURE ( 9.32 ) 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: Joel Fernandes , 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 , 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 l4jsirXri4jri6QuCiAKIAog6rCA7IOBIOuouOyLoCDqsozsiqTtirgKLS0gCjIuMjcuMC4zODMu ZzA1MDMxOWMyYWUtZ29vZwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f 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=-13.1 required=3.0 tests=BAYES_00,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=unavailable 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 BFD0CC433F2 for ; Fri, 10 Jul 2020 16:53:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A45A207BB for ; Fri, 10 Jul 2020 16:53:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594399985; bh=41KnUwWYjh1L4ww56o0v6hGwIPLLgxOofq56d83amoQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=sw7TG4wDflUGcehkis/eVuRWndwl/dsNUwMPUuwGeC2D6xbF8Kf+mpmlxm/5lMSaZ XktvX0qN1k1V2KxmNcsb9st8tdr5lPIobMHcLXymo9Hfs89pdiK1Y1VPiVyq3AX/5Y OvMn/Liz0jUcN2hK6scQ5pTt4RQMdGG8fSKgItIQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728519AbgGJQxE (ORCPT ); Fri, 10 Jul 2020 12:53:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:60054 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728461AbgGJQw5 (ORCPT ); Fri, 10 Jul 2020 12:52:57 -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 D4B2F206F4; Fri, 10 Jul 2020 16:52:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594399976; bh=41KnUwWYjh1L4ww56o0v6hGwIPLLgxOofq56d83amoQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O0jjZWL7mt0G7iW7zch92TtJ0Rj5J2tK8hjOCQCT6hUalwV6hHLRMKQ6BzYxt31kt Bp3takgf77JdKvrQ2+XZhS1O3g2rYt9m97eMu98EINHrX3BsBoDVdnG5p8vRGXZeF6 97jjEzPw3ZNRGBk2f0whnYPzbQ6d9PPFr9qBb+Qo= From: Will Deacon To: linux-kernel@vger.kernel.org Cc: Will Deacon , Joel Fernandes , Sami Tolvanen , Nick Desaulniers , Kees Cook , Marco Elver , "Paul E. McKenney" , 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 v3 11/19] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends() Date: Fri, 10 Jul 2020 17:51:55 +0100 Message-Id: <20200710165203.31284-12-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200710165203.31284-1-will@kernel.org> References: <20200710165203.31284-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.383.g050319c2ae-goog