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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8B44AC4828D for ; Thu, 1 Feb 2024 17:33:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ShWrgh2j1nty22JQe18W4JWfFbXifo0gTLike7IJw9M=; b=x78Wh556tqDxg9 HIsMjfiz2rIEki2h+9KiXndzxegkqGlCKdd5Ksh+BFmfWrFLyz865HxZkDEGR0KHoxR7Mu8Uu0m1O j9lXPRDykNAV+5VoQYqqXJshiy15lf6OOu+e17FTqxyiLdYVnN7OWyrb7tOL7sTpTyuvyKSzPJqIV kj5VWYUi5OdQO1tXVrIUlLSZM32rj1zGtxNDmrN2ZQAKRzYx/5r4+XEzoRqcbHlggbBhNF8vUqm1J 0CQ24octlWYPG2Ow6qMyk4GXFnwV/jGVH1l0RQCa3J166jZ8vSJO+0QkhK6LhCpLOT2N1ilCq/kH+ rkFriKt+VBQbg0igR0Mg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rVavu-00000008oKW-28EW; Thu, 01 Feb 2024 17:33:02 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rVavr-00000008oIY-3AXs for linux-arm-kernel@lists.infradead.org; Thu, 01 Feb 2024 17:33:01 +0000 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 DDF6DDA7; Thu, 1 Feb 2024 09:33:38 -0800 (PST) Received: from raptor (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5A62F3F738; Thu, 1 Feb 2024 09:32:51 -0800 (PST) Date: Thu, 1 Feb 2024 17:32:40 +0000 From: Alexandru Elisei To: Anshuman Khandual Cc: catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org, rppt@kernel.org, hughd@google.com, pcc@google.com, steven.price@arm.com, vincenzo.frascino@arm.com, david@redhat.com, eugenis@google.com, kcc@google.com, hyesoo.yu@samsung.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH RFC v3 12/35] mm: Call arch_swap_prepare_to_restore() before arch_swap_restore() Message-ID: References: <20240125164256.4147-1-alexandru.elisei@arm.com> <20240125164256.4147-13-alexandru.elisei@arm.com> <08a4971e-c31d-46f7-afbc-7404bd9a293f@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <08a4971e-c31d-46f7-afbc-7404bd9a293f@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240201_093259_869678_E7F446C9 X-CRM114-Status: GOOD ( 16.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Thu, Feb 01, 2024 at 09:00:23AM +0530, Anshuman Khandual wrote: > > > On 1/25/24 22:12, Alexandru Elisei wrote: > > arm64 uses arch_swap_restore() to restore saved tags before the page is > > swapped in and it's called in atomic context (with the ptl lock held). > > > > Introduce arch_swap_prepare_to_restore() that will allow an architecture to > > perform extra work during swap in and outside of a critical section. > > This will be used by arm64 to allocate a buffer in memory where to > > temporarily save tags if tag storage is not available for the page being > > swapped in. > > Just wondering if tag storage will always be unavailable for tagged pages > being swapped in ? OR there are cases where allocation might not even be In some (probably most) situations, tag storage will be available for the page that will be swapped in. That's because either the page will have been taken from the swap cache (which means it hasn't been freed, so it still has tag storage reserved) or it has been allocated with vma_alloc_folio() (when it's swapped back in in a VMA with VM_MTE set). I've explained a scenario where tags will be restored for a page without tag storage in patch #28 ("mte: swap: Handle tag restoring when missing tag storage") [1]. Basically, it's because tagged pages can be mapped as tagged in one VMA and untagged in another VMA; and swap tags are restored the first time a page is swapped back in, even if it's swapped in a VMA with MTE disabled. [1] https://lore.kernel.org/linux-arm-kernel/20240125164256.4147-29-alexandru.elisei@arm.com/ > required ? This prepare phase needs to be outside the critical section - > only because there might be memory allocations ? Yes, exactly. See patch above :) Thanks, Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel