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 18BD8C4829B for ; Mon, 12 Feb 2024 14:45:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8AB7F6B0071; Mon, 12 Feb 2024 09:45:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8349C6B0072; Mon, 12 Feb 2024 09:45:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D5376B0074; Mon, 12 Feb 2024 09:45:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 56A606B0071 for ; Mon, 12 Feb 2024 09:45:11 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0571880A70 for ; Mon, 12 Feb 2024 14:45:10 +0000 (UTC) X-FDA: 81783424422.24.B5CE491 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf25.hostedemail.com (Postfix) with ESMTP id 0E431A001D for ; Mon, 12 Feb 2024 14:45:07 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707749108; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=16qMSmAEvLPOcIqczpGhiqxJnkTMn5xlIaVWX44ktlc=; b=SpEYcBHPjkU+cyQDsTCEEwx94BWNABncaNMTUT2gyC8mB98c9wMu3Vp9xPq6E2PLigrgd7 Pf+zDziJLxcw5iHJU6CXaftJvtprtBekb1GF8lAxh1ILAIBpnKXmKeePIgWvbbaWgKzGI5 b5SNtC0se4BZun7jjKL3uL8zXl4PjVs= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707749108; a=rsa-sha256; cv=none; b=lOkHHryjrlxyOuoonNQ2RCW1a53PTJBb/shPJyHA1S1EKG+yi913pyc5ZRwz6jNh+0asqh 03a48+1Ym+tyAj6FFpQplRTeKXpUktbBEpEbz8Y5oO8nsWHZBPZMSmoYimoKJC52be1WoO CYJiJEk387scQe6Czeele6ulqyw0crE= 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 39022DA7; Mon, 12 Feb 2024 06:45:48 -0800 (PST) Received: from [10.57.78.115] (unknown [10.57.78.115]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8F7543F766; Mon, 12 Feb 2024 06:45:02 -0800 (PST) Message-ID: <502a3ea7-fd86-4314-8292-c7999eda92eb@arm.com> Date: Mon, 12 Feb 2024 14:45:00 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 19/25] arm64/mm: Wire up PTE_CONT for user mappings Content-Language: en-GB To: David Hildenbrand , Mark Rutland Cc: Catalin Marinas , Will Deacon , Ard Biesheuvel , Marc Zyngier , James Morse , Andrey Ryabinin , Andrew Morton , Matthew Wilcox , Kefeng Wang , John Hubbard , Zi Yan , Barry Song <21cnbao@gmail.com>, Alistair Popple , Yang Shi , Nicholas Piggin , Christophe Leroy , "Aneesh Kumar K.V" , "Naveen N. Rao" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240202080756.1453939-1-ryan.roberts@arm.com> <20240202080756.1453939-20-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0E431A001D X-Rspam-User: X-Stat-Signature: km4z5e4wcpya9rd6jcgzw74jszzapjmn X-Rspamd-Server: rspam01 X-HE-Tag: 1707749107-205185 X-HE-Meta: U2FsdGVkX182eVoMS9Khu1jw+jM6hV5Ydiy1T0el8ZcGn2GYATXYjdPs3T9nvgKzehffcdHR6VH0Oe5Nqt7CxxMOrqijfSkbt6aXgWT3UEdeeoAPhk0L/zaSMJEiRIf2iNxPveiUmra9b7LH8r7GN2Ujv61y3Vn+RE9VDkhWbbWCpR3QwGvVa66r9dLT1bASNJtFYdzfp4xGwwQLjTsmwrt5ZArbWIklb7ePyOCj+XqkwNqDojZaU5Dq9MXRG3b3e3W7rAifTS5dKGAf9lPy9vFtleAKrgPaMgkQXcHbI8sH5CW/yglR3SDB/pmGv95Q/xMjo2twtu0XY0qh6JP6N6QN38Ny5Jzb6Kqs4zZhBG7Jx37LTa8BYalbWC2K55wq48S94np9UPqFksLo4jOM39nPF1gGMZZdEHwr2A0URaOKwc67ILxBqF1+9aZ17oUFPPhe1rK5JZ9mkak/z3smhYwFOb/YxG7FG14xJSAwvuhdAtRFjtIu8IC/XC4me4Hksq0vqMoosubBOBLXfmUe5xwkX5H4xz/YSmElujeZPKGG/8VFiKpJkCkqtP9eKDJoaPqmQGlOSNmC//5LZIjtDA44O+SALF8VvgFAjXHVXvwz5wkX68BCUJC2zqWqvBcKkfmC3z8psONHQ7lCn8GBiQIX+adu7h7/K86mwrZ/pvW+Ys1UJeiJWyFdK8NpGpu/Mr1poyE05IqTKk7tmsWx9u6QAEAPKOXHMnEdBUusU08+pvTTVR1FO7/LGBjuGwTwS+89BzSzO6KWeO5OoclpugMvzXaqe96yWGFwy+XQXhMHREHy6hrcTEvoyJyCHbALJLAmVhSGav2IkNNuFXneArDbwt1ZvgZRf4hDhZ6fxEdiLNLXZc6V6ndSkHQOV3W90Kaog40vqAK78PVg+oI3VGYj7twoWpW7TV8U5xyiMOb47MeJQ5xV3rKxhF7rZLEgV7Q1S7mT9+CnO/VaSrj P4xuWmAT 0iLjCYB4vMJjT2eBXb3WAtoKxGKKdcixjXCZKHA0G7liwe/TnWZV8ojzmGjWhQp++Gcci7uMA1A4kHSxH9GLDuSlJeKetxWJoNeXOjxToWo5skyuc7n4hgagCL+yWgzFocCxSPN6MVYrRq/ThfDeFfxYRp8ebFAy8Lyhrv2Wgm0JAJryeDVbWrnbuU4OY0k8gjuMl4UQ86SKrt5nyKDAfNN0eEJkaAPBLDmjVgNobStukQX9Qniy3gBPZoWcI6V6s9Eg4AS5gSDk9tgA= 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 12/02/2024 13:54, David Hildenbrand wrote: >>> If so, I wonder if we could instead do that comparison modulo the access/dirty >>> bits, >> >> I think that would work - but will need to think a bit more on it. >> >>> and leave ptep_get_lockless() only reading a single entry? >> >> I think we will need to do something a bit less fragile. ptep_get() does collect >> the access/dirty bits so its confusing if ptep_get_lockless() doesn't IMHO. So >> we will likely want to rename the function and make its documentation explicit >> that it does not return those bits. >> >> ptep_get_lockless_noyoungdirty()? yuk... Any ideas? >> >> Of course if I could convince you the current implementation is safe, I might be >> able to sidestep this optimization until a later date? > > As discussed (and pointed out abive), there might be quite some callsites where > we don't really care about uptodate accessed/dirty bits -- where ptep_get() is > used nowadays. > > One way to approach that I had in mind was having an explicit interface: > > ptep_get() > ptep_get_uptodate() > ptep_get_lockless() > ptep_get_lockless_uptodate() Yes, I like the direction of this. I guess we anticipate that call sites requiring the "_uptodate" variant will be the minority so it makes sense to use the current names for the "_not_uptodate" variants? But to do a slow migration, it might be better/safer to have the weaker variant use the new name - that would allow us to downgrade one at a time? > > Especially the last one might not be needed. I've done a scan through the code and agree with Mark's original conclusions. Additionally, huge_pte_alloc() (which isn't used for arm64) doesn't rely on access/dirty info. So I think I could migrate everything to the weaker variant fairly easily. > > Futher, "uptodate" might not be the best choice because of PageUptodate() and > friends. But it's better than "youngdirty"/"noyoungdirty" IMHO. Certainly agree with "noyoungdirty" being a horrible name. How about "_sync" / "_nosync"? > > Of course, any such changes require care and are better done one step at at time > separately. > So I propose to introduce ptep_get_lockless_nosync() (name up for discussion) and migrate all users to it, as part of this series. This will side-step Mark's correctness concerns. We can add ptep_get_nosync() later and migrate slowly. Shout if you think this is a bad plan. Thanks, Ryan