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 51DDFC4828D for ; Wed, 7 Feb 2024 11:13:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 70EC26B0078; Wed, 7 Feb 2024 06:13:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BF4D6B007D; Wed, 7 Feb 2024 06:13:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 586E56B007E; Wed, 7 Feb 2024 06:13:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 44D066B0078 for ; Wed, 7 Feb 2024 06:13:07 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E39ED120CFE for ; Wed, 7 Feb 2024 11:13:06 +0000 (UTC) X-FDA: 81764745972.04.444B379 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf02.hostedemail.com (Postfix) with ESMTP id B28C380020 for ; Wed, 7 Feb 2024 11:13:03 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=BR7gVvcB; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of will@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707304384; 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:dkim-signature; bh=k6bynGvSB3bW4A1nOQ0Ulh3u69qvHB3qLOySjtY/DaM=; b=jhQOQziwYb5X5swDgc4Kj3+BnQo3cckNLgY2I4sdFOzAlF7nUyiV7BFGCel9zcgwJM4+qz MyPyFDe5mYvvz7304PDor+d4zC1S+JNlPTwovHWbD4fU2uhrSB/1XARPJtTNiDbn+tKZlW 71tHE2CVk7pj4u9en2MA4nPE9Vq2oTo= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=BR7gVvcB; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of will@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707304384; a=rsa-sha256; cv=none; b=oqr7H4X0NqzLDeB75ksLzLkeDbq/0KKTpYsIa+f+n37JrucnA47NKA+pV4NXnod++BCXBs GGa4IBQ8O6C9FHayJTDtrnDdJiFoFFk7MmlSJKzFr05AXjfjG/5H9DKDV6YVvOrQ0MmjBO EieF2KVQLFqAj5mw4NA4UCYJKBtCeUo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 419CDCE1381; Wed, 7 Feb 2024 11:12:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D42EC433F1; Wed, 7 Feb 2024 11:12:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707304378; bh=Wdwlj8End667TasRIp745gWvCi1r+Z+ho/QV9RjE1iM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BR7gVvcBwGGbvbZfh7xizzOqoGFPTI0JQWsV7ndm9o6m3Ea8vwZVbv/9ygor6Vx4W qZU5i/hgHxS9F7vgiKb3m/YM9C/JQbILhIG58u0xr8GwjEynXC2o3FUpkX47vTzBi8 RT9oYPYnBzc0lcB6QUQLHD0HHuF3CLlRn8+0pMlp4pHpTrSzJvCK8c833CQRRJocLl GFhSagN7yVuG0QqORcjvg+FhmUtwd9Sj+LddWIN4v+MloroBcWy7FADQHVWahafU0g G3+NbfE6o/szBGOVSMw+nHdIA2eEeqzrlm5STgTFp38hcoaDdLcmo9CWKbu4rEa89X xaS/xIlnSDqzg== Date: Wed, 7 Feb 2024 11:12:52 +0000 From: Will Deacon To: Nanyong Sun Cc: Catalin Marinas , mike.kravetz@oracle.com, muchun.song@linux.dev, akpm@linux-foundation.org, anshuman.khandual@arm.com, willy@infradead.org, wangkefeng.wang@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v3 0/3] A Solution to Re-enable hugetlb vmemmap optimize Message-ID: <20240207111252.GA22167@willie-the-truck> References: <20240113094436.2506396-1-sunnanyong@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: B28C380020 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 5mwmz4atpi9ce431bdjqsztzx5ecg684 X-HE-Tag: 1707304383-696594 X-HE-Meta: U2FsdGVkX18qiuawCPVtcepWAetbmY1TPTfzVeal4KmW4C8GaaRIuheVFasPVowZzV5eMx7zeJRk3R4mMNk65Rr0hU8J5UiFQAYVFaxlk50yIOc9/rcBADMvqGbpvJC5BBaBZDJjuIRVW/cPDDFr3BlggVjBF+PXkuwWMB45Vt/sxqypME9KREg7sPomYJvapaB6ItqBN1XkdafGVnd1dsfNeTFwIt8uAPMEYy4aw1o/HPPl7v8KJ8t999PSLLChugdVxfhue47pbrIiV1VvySn6QQKy2vmXkUAmkfwRiEhL1fp4wwIhzZB2aC0YTWPGtcBg2oOwNWL5P5aq+XXLEj5X2396R1gM4ycRIIbz74W6owl1Zz3W+QJd6wagMPUz+t3KoJP3UYq2biWqUzsooTgwOKWg2zYG1BaomWKTLXQH8YhC1+FTIQUDxSMNNdBqzEZUPItbslBbRvLFecgZBKi/GLlZUmpruwxcjwY7uskX7jf0pY7dNaVC6FUgZCMWGBFdrPcf/Jd2LYDbGG35C3cu+u79wdWC+OCAIOsCqoSRupLJb+rYUueZtaXWJVmmYzb9BLOjZHjWyS34KAoRNDQZOwWGAD2RmcUMGRmLH0Nrs8D/IE2+OQOkMYJ1I+Iho06oSE/Cx5ZB/FSR/bH6RUEWGMTOisPHz0lrqvGU2g6bLXgiXiTxNjnDZJk6zdSPw4qxGsXMPvyg+1WcaWuCLd0P5Y6HIGZ9TTJsyc7HOB+PhTAqT1KxXC+htKSIwfUmC6U5BN8HhzSSK/5qeKoctIXxH1jCpAf39PUg3a6wdC5y0nQHcmhhNMia5ArPb+hr+lniyBnUE/faCAMBRnBSLmXq1Nf6gT8aN2QmJ10WDosUoOyXK6EwyRIVAVji2RkZP+seruFtwk6i1pUe1izgTYJbFb1yoBPIQiD+dP70S/3uYaQkw8vVnSYCsQf+i7ytNaF7GhdrTG9R0fKk+iW 9KiR0/+F tUJJsDV+sUPtRA4umZoNK60l0i0Rsdt/sIb2TOrMXWtJvJ3SB+tG7sXoUdn+1AXCQT9KQ7OJcTBIM9lkNuX12jdQsCwKt8WGf/QAjBOkcZWDIrnknr2ZHIN2na9jbQPI+DDE1BRyLZOAQbc2pb74AUEkpWG56UKOJvyTxATg5eAtxnagQXOnuRi/kCDODEJw5o/x9uiqvtGII65gawQN23XOCPw== 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 Sat, Jan 27, 2024 at 01:04:15PM +0800, Nanyong Sun wrote: > > On 2024/1/26 2:06, Catalin Marinas wrote: > > On Sat, Jan 13, 2024 at 05:44:33PM +0800, Nanyong Sun wrote: > > > HVO was previously disabled on arm64 [1] due to the lack of necessary > > > BBM(break-before-make) logic when changing page tables. > > > This set of patches fix this by adding necessary BBM sequence when > > > changing page table, and supporting vmemmap page fault handling to > > > fixup kernel address translation fault if vmemmap is concurrently accessed. > > I'm not keen on this approach. I'm not even sure it's safe. In the > > second patch, you take the init_mm.page_table_lock on the fault path but > > are we sure this is unlocked when the fault was taken? > I think this situation is impossible. In the implementation of the second > patch, when the page table is being corrupted > (the time window when a page fault may occur), vmemmap_update_pte() already > holds the init_mm.page_table_lock, > and unlock it until page table update is done.Another thread could not hold > the init_mm.page_table_lock and > also trigger a page fault at the same time. > If I have missed any points in my thinking, please correct me. Thank you. It still strikes me as incredibly fragile to handle the fault and trying to reason about all the users of 'struct page' is impossible. For example, can the fault happen from irq context? If we want to optimise the vmemmap mapping for arm64, I think we need to consider approaches which avoid the possibility of the fault altogether. It's more complicated to implement, but I think it would be a lot more robust. Andrew -- please can you drop these from -next? Thanks, Will