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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A249C48286 for ; Thu, 1 Feb 2024 17:33:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE4A56B0082; Thu, 1 Feb 2024 12:32:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DBB1C6B0087; Thu, 1 Feb 2024 12:32:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD1AF6B0088; Thu, 1 Feb 2024 12:32:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BDDCC6B0082 for ; Thu, 1 Feb 2024 12:32:59 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 968FAA0963 for ; Thu, 1 Feb 2024 17:32:59 +0000 (UTC) X-FDA: 81743930478.22.109D319 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf05.hostedemail.com (Postfix) with ESMTP id AEBAA10002B for ; Thu, 1 Feb 2024 17:32:57 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf05.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706808778; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VO6qeLEUTVMAQo0aKaGLr8oCwzfIdJ93nyIqc1W5YCE=; b=IPcj23OAXHwsb2Fz9Pd6lvnfivQYicJzp6WzmGLNocADs/5gLqe3SkKsouWuyPc7dg6EXy W3H4MFdIYovg7OHk+EN8imE8tFp3udJjs67Tz7+Ct6Hpzwv+riEL3QCt/sDvjEHFkuqhuK WJuSKe4EmU8Duuo3p3c12TrJkNJvdhE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf05.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706808778; a=rsa-sha256; cv=none; b=LbpDAmMSBhSHF7JC/DKP6CgHdUnEGtuTyF0v/cJgPksteGxA9rlrD82AWlYdJll2mv4mJc 0if4y/eCtfoOkf9F7oMk93TJK+CM2/h+rhB0Xyh7B2O9t9NmT+7KZqcCvMnqTvFxCh4eWt pPTudRm0z+pHf83YZTYR3W7MR5yyTBs= 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08a4971e-c31d-46f7-afbc-7404bd9a293f@arm.com> X-Rspam-User: X-Stat-Signature: okty5w8n19x4n3j9s86h7rf5ai1ngdna X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AEBAA10002B X-HE-Tag: 1706808777-291358 X-HE-Meta: U2FsdGVkX19oWS2cAAkpxjRaeiJun3EWdUc91mxx67lBDNfjooJWc1D1bqSQW5qQWT7sn/pGoJAd45lXMtCshkRBuAqj19AUyAXeUpUL+IGRr1Suytxr23TZypyc6GyNpG4lBGb6ME3DDqmP/GQL9SZ9saXvfTCd9EL+2SzJIFvjco90vc5E/s+c63qKX7EMUzK1ajURhrBtoliBgiyBT3So1TywLQFt+mmxhp0cf+csHkUaUtJO0pDlhr1zyqc0ZTv/y02DN2hUS5iNXFdXW37/M1noQoYpNzq4E6ra+0VIb2YAkvFyn1qt4CMJF563DMghtVnWKRCaPAUeUkSWwrYkmTZtNbvAMtyHlAqDqsUish+i2E3sWbSbW6FD7oFSesV5yJndNM+DWA+YhrVT1D20GtVh2zKwlkA7W+PQSmvD7jZJ77jyW8D/2dmbtxKtS9Pb6pdzeNnl3JouLReNFmtJrafNsZDSXyCrjzY1PZaxlUVBzDSmRMcUb7qPocqJ6e4GvOzy/Bx+GBTrfFVpaFvo3TC6USvGkrgqRWCpXZx0IHx8wiZ48f5HQopyqzsfbuqCXYRlNqS9+dxJsi4hNFRRwVDmOA1gmqZve/NQ8xO2eqi4RDZ5bcdg5UBeLwn9Nx5XiVSxFxZxPKJA9ZmwyzhwbMl6D9fVtKDcUVE9lEO/qIhJnR6b7UKuW6cYPp3Xa9tnJJjxsAZCfvFjIAD09fwk4N/WO1cuOp3/y5a9hZxCPMBNHxOoXlRX2RV5L8PAiP/KUEEhrX/Uk2lo/uuoH8FFHBAQq6Sav3vuRXVahEt8Khy7Y1RnR28etwr//ivpv6T1G079Mc6X3S2VDTONEKraDCAGT5tu 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: List-Subscribe: List-Unsubscribe: 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