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 B9D19C021B8 for ; Tue, 25 Feb 2025 17:52:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB01028000B; Tue, 25 Feb 2025 12:52:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E60CA280008; Tue, 25 Feb 2025 12:52:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D4F6A28000B; Tue, 25 Feb 2025 12:52:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B6315280008 for ; Tue, 25 Feb 2025 12:52:33 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4238D1C791A for ; Tue, 25 Feb 2025 17:52:33 +0000 (UTC) X-FDA: 83159211786.30.375294C Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf23.hostedemail.com (Postfix) with ESMTP id A0A67140006 for ; Tue, 25 Feb 2025 17:52:31 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf23.hostedemail.com: domain of cmarinas@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740505951; 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=TDbhABUS9urbjuK93orrRgVMLJaDNVuhJFFht39PZ4Q=; b=fWoUN8GNiPZyPRpVt+ymtSDs1VkTDBbnT1bghwaho5E76D5TZkGPf7wQhYBssF22ClVgVf whVXiG7OCxTclZCxk6NEfIBod6el9jTFbN8FdHXut/nHws+XQdHDbGHu3iXXbHtsI7Voch Sl2cYZ9RbcNTfPE0VrMKQKzw2dXcS/w= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf23.hostedemail.com: domain of cmarinas@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740505951; a=rsa-sha256; cv=none; b=JGTP/CxeguAe+BIqvrQkuLW9XeGyH7isGSesBzqlZYpQV/YxOZr0Nr/CzWDfbVUtGstrpr ekF+mVgmCwRE4BGX6Q6dqUS4LiDt6G1sRj1mj9vb8g/Zs5F5pvzJ1/AIFQbppK4MJRxEW/ bAI4EywHDq4XtKn/Ikh4utJf99FZuyY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id D8FB7612B1; Tue, 25 Feb 2025 17:52:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00DDDC4CEDD; Tue, 25 Feb 2025 17:52:27 +0000 (UTC) Date: Tue, 25 Feb 2025 17:52:25 +0000 From: Catalin Marinas To: Ryan Roberts Cc: Will Deacon , Pasha Tatashin , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , David Hildenbrand , "Matthew Wilcox (Oracle)" , Mark Rutland , Anshuman Khandual , Alexandre Ghiti , Kevin Brodsky , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 12/14] mm: Generalize arch_sync_kernel_mappings() Message-ID: References: <20250217140809.1702789-1-ryan.roberts@arm.com> <20250217140809.1702789-13-ryan.roberts@arm.com> <4fad245f-a8a6-468b-82d5-13f089aa525b@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4fad245f-a8a6-468b-82d5-13f089aa525b@arm.com> X-Rspam-User: X-Stat-Signature: rhohrgzrz3w1p11j51yabqbx9pig5abm X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A0A67140006 X-HE-Tag: 1740505951-580420 X-HE-Meta: U2FsdGVkX19K2k1OTWl2adGJ4MDNoPJ4Jx5OutvJniNmnC0QEoobsGywkwQW3sCicuzfMywe9A6Z3vJG0bTjB7fZwGxZTpxY/rZhaX3WxaI2/xGhYF7Jt2YvB7OeyxpiZEWKUC5I1oBMWok+GGosEHURdq/7EuVaJDye0oe0eiIe+zBvui/zqTVAkjvW4602/CT/COt36KDE5/ebCWhJh/j3qSQqXeabN9gRbTIjL91rjEmNxUBFN/2Xo9d7C1Pl0zz15i1oKRizCBSOFlvUZz56NWfM85lSAA9AwQCdpn/0StRboOzRYvEDJQaOSxgRWZxO7QAY+P12CF+PchQy8oI0jF7H7jZQ6s4xklgIdqAVjnSpfy7vP7nUoXb8jbpVRwaLuUgJYARlR4Gdr4gzw4TUnjeZL8RpOARY4Ni6odYLhAZMY4/bMbYdh9ttvavk1V3f+Nj/aHP197W0F3EXSf0s5E60xQbCytUoLnGnT0XgFUYesOms5tyahj2yn8kEAnuJUP44dez5H3dWERY428BBQDi71YIkH2qxDU4SYe5Nqb6ZQXRmeroe8duD1b4nZbCIBMwOUbwJggtgSvlKSQE2JL70YkSzJRdN1JBdNu134CLxjRNl/+zLNgQMPhjbfLgRneQjPTY06g/LrKCzIlGUz0qKW2IGlgBd4IGEVLj6iOpPjoDCqOxXiinAig3RVBwgJw/QhobKnXeIQKusc5ZKBvP1wsvtLXWIozUYyCLQMedk//7ysJCW3MwL38fhnJdDzzZ7BzvfXAg6hAmae+yCpx5Xar6K0P4ISfu7Q5K0QhOOr+wV5SKpjNI8oNzv1RnVxKlPDgSkhPGbIL7CL6iI91afnCrVzf4gr2BrhCQNUCUfSb7Ry3lN1ecOMehwTV7LI/FN70bQwzbkVWCqnpCOopx5+NgtUKqK3GYKsa4eQLDGuG8s9HEorBPQDVvAnhNiLOS9kg/FrL3b5I6 ++inZjFL R0ZecZmBKBgUlBHe2QgkJpY0ttnc3oSJ1/xnnjHfG/uvr8Lbsc8+g0+KG4HPi1CHBADRffoCQOenxg1mR4NclwXB4qXm+arxlCYs962S9UGpBTqnV5aX1lyyLAUWpZX7ZkT2D2ig6xlpbIhMjYu8gXVbVBNfKfCVG6gDYMOwsK45T8xKCDRZsf1nFdTWJ8bANn3ZvsYSn1O12XPzj/M72FhrBSe0czD9BW9ZiBNBP2myGeOKEyZtqOxSHyTB5yiiD7O+6oLffKzkvcZ2Kc+mBpQHxsDbu9lro0Vhxx7WtyfDUJZq5mY728xFVYxJ8puLD0AK2TASav2A0lj1Gy1v9uj538aB6ibTF+5Fsmbm/kc3NN7+mVHzSuXnDHvcdu6GyyliFNZb9cw3lG9s= 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: On Tue, Feb 25, 2025 at 05:10:10PM +0000, Ryan Roberts wrote: > On 17/02/2025 14:08, Ryan Roberts wrote: > > arch_sync_kernel_mappings() is an optional hook for arches to allow them > > to synchonize certain levels of the kernel pgtables after modification. > > But arm64 could benefit from a hook similar to this, paired with a call > > prior to starting the batch of modifications. > > > > So let's introduce arch_update_kernel_mappings_begin() and > > arch_update_kernel_mappings_end(). Both have a default implementation > > which can be overridden by the arch code. The default for the former is > > a nop, and the default for the latter is to call > > arch_sync_kernel_mappings(), so the latter replaces previous > > arch_sync_kernel_mappings() callsites. So by default, the resulting > > behaviour is unchanged. > > Thanks to Kevin Brodsky; after some discussion we realised that while this works > on arm64 today, it isn't really robust in general. [...] > As an alternative, I'm proposing to remove this change (keeping > arch_sync_kernel_mappings() as it was), and instead start wrapping the vmap pte > table walker functions with > arch_enter_lazy_mmu_mode()/arch_exit_lazy_mmu_mode(). I came to the same conclusion why looking at the last three patches. I'm also not a fan of relying on a TIF flag for batching. > These have a smaller scope > so there is no risk of the nesting (pgtable allocations happen outside the > scope). arm64 will then use these lazy mmu hooks for it's purpose of deferring > barriers. There might be a small amount of performance loss due to the reduced > scope, but I'm guessing most of the performance is in batching the operations of > a single pte table. > > One wrinkle is that arm64 needs to know if we are operating on kernel or user > mappings in lazy mode. The lazy_mmu hooks apply to both kernel and user > mappings, unlike my previous method which were kernel only. So I'm proposing to > pass mm to arch_enter_lazy_mmu_mode(). Note that we have the efi_mm that uses PAGE_KERNEL prot bits while your code only checks for init_mm after patch 13. -- Catalin