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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 C539CC54FCB for ; Thu, 23 Apr 2020 12:37:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8CA942074F for ; Thu, 23 Apr 2020 12:37:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8CA942074F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 234EF8E0005; Thu, 23 Apr 2020 08:37:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20BD28E0003; Thu, 23 Apr 2020 08:37:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D3F38E0005; Thu, 23 Apr 2020 08:37:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0031.hostedemail.com [216.40.44.31]) by kanga.kvack.org (Postfix) with ESMTP id E4C408E0003 for ; Thu, 23 Apr 2020 08:37:27 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A492B181AC9CC for ; Thu, 23 Apr 2020 12:37:27 +0000 (UTC) X-FDA: 76739070534.27.color19_4114ae61e6624 X-HE-Tag: color19_4114ae61e6624 X-Filterd-Recvd-Size: 3025 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Thu, 23 Apr 2020 12:37:27 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 42E2431B; Thu, 23 Apr 2020 05:37:26 -0700 (PDT) Received: from [192.168.1.84] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 458F23F6CF; Thu, 23 Apr 2020 05:37:24 -0700 (PDT) Subject: Re: [PATCH 2/4] mm: Add arch hooks for saving/restoring tags To: Catalin Marinas , Dave Hansen Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, Andrew Morton , Arnd Bergmann , Hugh Dickins , Vincenzo Frascino , Will Deacon References: <20200422142530.32619-1-steven.price@arm.com> <20200422142530.32619-3-steven.price@arm.com> <20200423090919.GA4963@gaia> From: Steven Price Message-ID: <380bdf0b-aa7c-399c-d16d-b2aecd3f363c@arm.com> Date: Thu, 23 Apr 2020 13:37:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200423090919.GA4963@gaia> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 23/04/2020 10:09, Catalin Marinas wrote: > On Wed, Apr 22, 2020 at 11:08:10AM -0700, Dave Hansen wrote: >> On 4/22/20 7:25 AM, Steven Price wrote: >>> Three new hooks are added to the swap code: >>> * arch_prepare_to_swap() and >>> * arch_swap_invalidate_page() / arch_swap_invalidate_area(). >>> One new hook is added to shmem: >>> * arch_swap_restore_tags() >> >> How do the tags get restored outside of the shmem path? I was expecting >> to see more arch_swap_restore_tags() sites. > > The restoring is done via set_pte_at() -> mte_sync_tags() -> > mte_restore_tags() in the arch code (see patch 3). > arch_swap_restore_tags() just calls mte_restore_tags() directly. > > shmem is slightly problematic as it moves the page from the swap cache > to the shmem one and I think arch_swap_invalidate_page() would have > already been called by the time we get to set_pte_at() (Steven can > correct me if I got this wrong). That's correct - shmem can pull in pages (into it's own cache) and invalidate the swap entries without any process having a PTE restored. So we need to hook shmem to restore the tags even though there's no PTE restored yet. The set_pte_at() 'trick' enables delaying the restoring of the tags (in the usual case) until the I/O for the page has completed, which might be necessary in some cases if the I/O can clobber the tags in memory. I couldn't find a better way of hooking this. Steve