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 C2F46D69113 for ; Thu, 28 Nov 2024 14:20:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E5FA6B0083; Thu, 28 Nov 2024 09:20:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 196016B0085; Thu, 28 Nov 2024 09:20:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05E5B6B0088; Thu, 28 Nov 2024 09:20:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DC9186B0083 for ; Thu, 28 Nov 2024 09:20:37 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8B88240161 for ; Thu, 28 Nov 2024 14:20:37 +0000 (UTC) X-FDA: 82835714094.27.BF6D575 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf23.hostedemail.com (Postfix) with ESMTP id 26CB8140004 for ; Thu, 28 Nov 2024 14:20:30 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GnhZS14a; spf=pass (imf23.hostedemail.com: domain of will@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732803628; 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:dkim-signature; bh=zk+38GcVkHyfGsfMVYqHv5jFWy+UyzxE4EWE+6e9rBE=; b=GGAlatpy4MhfQlwf+j1UyVY2vtE33fCTqI0S43zaHwnJ63z0HBpGjZ/QJO9DG/iYjokPV8 fl5bPAKsJenVlJrHxRNC4iVxqzf6gSYEMV2zFtc9Swqw79VAU9ljws4AXXFFxqN9uT4Xf4 /Ebt4W1bt+5Eii22lzUEjjAc6BpuPwA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732803628; a=rsa-sha256; cv=none; b=UPQD6td47Zvvcmgi2+AAuL+tX9WWEFp3IMFVLB8MSh09wca4bq7WkfnAfJqbP7QSWbHisl YPvPFcl497ACGb4+FERb1pQxZl3tept837ixSAo5NOYMzyyhmemt0V4fN09gjIT1XgNXz5 /VMjyntsTA09YmF/4R3IYSkPVrgc71I= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GnhZS14a; spf=pass (imf23.hostedemail.com: domain of will@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 1DE9AA43BE7; Thu, 28 Nov 2024 14:18:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F6D3C4CECE; Thu, 28 Nov 2024 14:20:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732803634; bh=qLn7KCjfeNms18fyJ3R4Q7z/HaY/qcbgERgC7rBSsrk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GnhZS14aE5CoghTDrv+dKiJwvpB9YXrZuVykroRSy9YysOGGCj0sGW1lbtqp5rxGE E2szlbIyPkxndDXy6WDDz+5pQIpCQxO2/ue+2b10hELPyifwRFA150KkZIj0sATc3e 9LbIwSZI1OJDANcRomO7I2aF+owml7Lo9HMBg65LWXGfgfW2MI+6ckPLFeMMy7lkPn gJYAoLN4sscAXjMOHJBZ+Q1XCO3vfy7230pNkFexFrHUTNYXU1kGI80o7iiWkvTpCC Odt9M6KdWxJfgJ5hlw1WHKuetIRjZTyxsZmG2FXwt7ErUJe+YRQvSLTONY81VgCX9a O776BICHiG4GQ== Date: Thu, 28 Nov 2024 14:20:28 +0000 From: Will Deacon To: Yu Zhao Cc: Andrew Morton , Catalin Marinas , Marc Zyngier , Muchun Song , Thomas Gleixner , Douglas Anderson , Mark Rutland , Nanyong Sun , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 0/6] mm/arm64: re-enable HVO Message-ID: <20241128142028.GA3506@willie-the-truck> References: <20241107202033.2721681-1-yuzhao@google.com> <20241125152203.GA954@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 26CB8140004 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: kfy6ke9zykydyhxhc7fq4j9bdn3f3yik X-HE-Tag: 1732803630-155234 X-HE-Meta: U2FsdGVkX18IvRiDXPUu65vWHV7/ZI3iSn4GrmlKa1yPC5hxbM17Tv7fSUpfXZblTvI4KBF2Xbpgc/xSImtDNBnZ17vWPNA3RMWiOk6DHIdMxJltllOO1Ksq/XvG3Sh8H222cPXuWIUuYASqSwm3uccwX5Px6CicbmfeftQFttOcqlJhCC2bQcO19Dl90p+F2ddrwWlWV96jIABeuMVmZPUEPu/BTl6OSSNtCSM5YDEGHDZlEVXMXO5t1SYh5cMi6ghre/4bGcJVop4s+oRhN8fPFqVsOCfBWyYiACBAcU9oNx2aj1qGGblU3LyzajQJChVCfrVw+IQ0qA5cQYJfKxXBghTOSeaKHtbPI228Ij4RiNVL4w0iE/Sj6MH0+KE2wp8fYhOrwaO//AEO+s63C5T+MDKCwLFWIDRXCyigLeoRmd5mX71K0ervdyYkqp1i7TIwxxLr/zu+OYobjgFdtOSVQs7us78yFTOUJoHl98h074vZcDMPQ9WFPo8CIkGgl6C+jT6p+b9On2XjiS7hxP+3VwbpxJ5EkJF/eJwDeB7+RytFoZ75Hz/j/6f6gK/cqk4zQHpt5qD+cbboj/Hr4JOQlsyim9oSFIGNu1a8/c+ITGD4hTC7HjtHjl01rFjSJM8vUKFmmbQPWPAYHPIpsYqsS+VGvLfy2TdR/Lnc8mqPyyGzNEM3KHyqwvG3W2PGDRLyN0b7o5nEpRxwXY2WCGe2u1Cx2EWlFbHOey8GNDq3qVtnln7xwEkRC/dvLqfSJG4UBQF6Wa6cDkT2mWoK/8KOVYi8k1HSWGTOEg8AYVaVUBWwyvSQJFafDQrPvfG1K2s6hjYG/B0UwB0iVb0xAAznGXZS/yse9hF5u3AoTfZA+BYjJ2uyqdDrbcV9nPCV9zfnnVJpZqUlB19hrBQ8cOEqpxTg9hGuQ0TtxjUAsLiP/LXhzB5kpfOy9JQfZoags+I1N8Vi5VJJ4ssotxc ZTgPZkN4 PfcJghvJ/hhqC/VId8rvDrzvYyY+Yntd3kgwRmWfGmLNP9+x8PJwlvr/enP4er1Sufk3tFzwtadm48M68D/BJCSw5LET9M+DFJJzZThub8OGUepU7k3tbJs669u+uQZzWe0IeqMbqHkjli0/z1laiH6iODNPSLvWtq6BnMdd5tCxE47Ju/+TdknKlgdPqkNPcF+3N78shxNl5FUgn+M6V/UN1d00KtzETT+x0lrT126lLzVs3UTurzzH4SnxvYovlC5dHeHIrUyOgd7U= 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 Mon, Nov 25, 2024 at 03:22:47PM -0700, Yu Zhao wrote: > On Mon, Nov 25, 2024 at 8:22 AM Will Deacon wrote: > > On Thu, Nov 07, 2024 at 01:20:27PM -0700, Yu Zhao wrote: > > > HVO was disabled by commit 060a2c92d1b6 ("arm64: mm: hugetlb: Disable > > > HUGETLB_PAGE_OPTIMIZE_VMEMMAP") due to the following reason: > > > > > > This is deemed UNPREDICTABLE by the Arm architecture without a > > > break-before-make sequence (make the PTE invalid, TLBI, write the > > > new valid PTE). However, such sequence is not possible since the > > > vmemmap may be concurrently accessed by the kernel. > > > > > > This series presents one of the previously discussed approaches to > > > re-enable HugeTLB Vmemmap Optimization (HVO) on arm64. > > > > Before jumping into the new mechanisms here, I'd really like to > > understand how the current code is intended to work in the relatively > > simple case where the vmemmap is page-mapped to start with (i.e. when we > > don't need to worry about block-splitting). > > > > In that case, who are the concurrent users of the vmemmap that we need > > to worry about? > > Any speculative PFN walkers who either only read `struct page[]` or > attempt to increment page->_refcount if it's not zero. > > > Is it solely speculative references via > > page_ref_add_unless() or are there others? > > page_ref_add_unless() needs to be successful before writes can follow; > speculative reads are always allowed. > > > Looking at page_ref_add_unless(), what serialises that against > > __hugetlb_vmemmap_restore_folio()? I see there's a synchronize_rcu() > > call in the latter, but what prevents an RCU reader coming in > > immediately after that? > > In page_ref_add_unless(), the condtion `!page_is_fake_head(page) && > page_ref_count(page)` returns false before a PTE becomes RO. > > For HVO, i.e., a PTE being switched from RW to RO, page_ref_count() is > frozen (remains zero), followed by synchronize_rcu(). After the > switch, page_is_fake_head() is true and it appears before > page_ref_count() is unfrozen (become non-zero), so the condition > remains false. > > For de-HVO, i.e., a PTE being switched from RO to RW, page_ref_count() > again is frozen, followed by synchronize_rcu(). Only this time > page_is_fake_head() is false after the switch, and again it appears > before page_ref_count() is unfrozen. To answer your question, readers > coming in immediately after that won't be able to see non-zero > page_ref_count() before it sees page_is_fake_head() being false. IOW, > regarding whether it is RW, the condition can be false negative but > never false positive. Thanks, but I'm still not seeing how this works. When you say "appears before", I don't see any memory barriers in page_ref_add_unless() that enforce that e.g. the refcount and the flags are checked in order and I can't see how the synchronize_rcu() helps either as it's called really earlyi (I think that's just there for the static key). If page_is_fake_head() is reliable, then I'm thinking we could use that to steer page_ref_add_unless() away from the tail pages during the remapping operations and it would be fine to use a break-before-make sequence. Will