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 47A21C4828F for ; Wed, 7 Feb 2024 11:21:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B09FC6B0075; Wed, 7 Feb 2024 06:21:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ABA0D6B007D; Wed, 7 Feb 2024 06:21:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A8B06B007E; Wed, 7 Feb 2024 06:21:33 -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 8B2A16B0075 for ; Wed, 7 Feb 2024 06:21:33 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 18D60A235F for ; Wed, 7 Feb 2024 11:21:33 +0000 (UTC) X-FDA: 81764767266.02.88ED135 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf21.hostedemail.com (Postfix) with ESMTP id DCEC41C0004 for ; Wed, 7 Feb 2024 11:21:30 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ImxC9KpO; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707304891; a=rsa-sha256; cv=none; b=vfl5YUKiQ5F3ZCWFSRT9YFZiOqQORkiAjpq1lAJzAQ4UvSD3O47ElPQLu17bCJhkveihwd 5SQZaI3gh8kGZqt0wp0fTFOFvO2UnqCfiKeZ/5JPv2MmXREzsQ0vJn8nQYEei4Mkeopx4P 4K9AzmmGlJYfn4px3xavasHQ6bKR2EQ= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ImxC9KpO; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707304891; 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=WpX5mJ+dnqA+dv/RTqJrWW+rQFLmTBT94nD0uWiwdMI=; b=h6iCrq659UMlP4UyVLLlEXpA+3JXH9EjgS3I0U8IDCLdi4fvLlSQHIs+/IRtvDGcF1R6ru nPxCnBF1VmZF6+c0dzvktvRH1cy4U95Yh02FupDECTNwFPXOhPlBLN6qM4dvFF2QTPP8cY ZLTrQ4WneZNp07eW28lJgqKNqglCqpk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=WpX5mJ+dnqA+dv/RTqJrWW+rQFLmTBT94nD0uWiwdMI=; b=ImxC9KpOSn9Kp0yFacpAPbEXBC QgbMi18qkmmyI9lmhwLdu/xEpKlsg9SptWborQ7SxET2RfEPO+Etjs97p0IoPatPFO8iaA7bC36YI e7WvpDgWq+MzGUdEBxK7cVsjWIRazsEidEFb/U+NdZDDGTs8FISZ6QMNvr3SjN6CZ7a6bkW+ioYky UEjihsZRLEASsrjmij8aP/NxFrPSfPJaX2CgtUHmVgu5Wj6uwoNAH+PFymrZivF7DJhEoTOvsTqiF fpw9JM9IxVo6HV5JHCv3GF301Y0zZnQF2HU2kGXzcDvZb+6pIdofdsvOGJtPSayOiLNECLLfJVaRE dl3sWP0Q==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rXfzR-0000000EzNf-1XL0; Wed, 07 Feb 2024 11:21:17 +0000 Date: Wed, 7 Feb 2024 11:21:17 +0000 From: Matthew Wilcox To: Will Deacon Cc: Nanyong Sun , Catalin Marinas , mike.kravetz@oracle.com, muchun.song@linux.dev, akpm@linux-foundation.org, anshuman.khandual@arm.com, 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: References: <20240113094436.2506396-1-sunnanyong@huawei.com> <20240207111252.GA22167@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240207111252.GA22167@willie-the-truck> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: DCEC41C0004 X-Stat-Signature: os1cbfr91tc4yyfoaxu9yq3aaidys7hs X-Rspam-User: X-HE-Tag: 1707304890-235010 X-HE-Meta: U2FsdGVkX1/ZJhMi+TXn3HBKsafbb182qzaNInPmKZ0h21PCuTmzyZaUiKnC9Twu9i+TtpVO5uuhlgxJvV5YvJ0P8wnsBVT3Ld8vFETa2opUxLX3prqUIxM2/2jRQjaJC5K4ZCTl0z91HkJ/7aR8VbIIszKoUFNDb7sXTlN/RJcaM5jZErwJ5rDWfbrXEUF3qX9vLuhk7AQg7p4HhFQ1txGXVr4IKLa3V5p6ojlW5OdrskMxsW7yQWT9tjgJdh+lauflD1jhdmCw4jU86oZUVt0TxhpuFdfGF+72yK0mS8ef8aCzv3Vb+Qv+l+NfViQxSCIOz4WJ/BYbif5MPbZI/j1ZLQxiCmuGzJ2LV5FHzg+HhP1r4ThoLRyuENQm8fxIEu9nSaBWZsGZ6vKYiI38aZwLmRb07r7aK+X4GHJWC43sX8tLsITUAHtDbYtADnfL+yFtjYK3DGdJfybLWcvVT4STz+MAdsAe/EhrBf6Z3jgWEqELee0RffZltRPDh+Wor/qydBdPBR64G07HCUC3acOSD4d6qR0TsQX2e6ggmlJbEFPxJ9rZ7qE6LQFB/qd7MJLBivfQrusixgPnl1l1TMKt9fx2Cy/r8v/Pv7IPp7kEh5Y+wu/dAx7Wk4dIDjREoEnvCsO3Lm0HNIpm7uWTc9wmkSUw3b83avN4JGgmtkCLr3Bi0tcUUJug9B9dZ5Rxp1myQ334xXT6TF+ELxuogWhAtFY5/5ZykMSMnMcXP3m8OVMA4kRuHdAZo33kvlzqv7lW1UfODofeCHdI1zaCJDTqJF36TrDfm1ALlPvr3t+WNg6ZyPcFp3qb/WF7A7stQnm+JjqizjUFZeJhFa5bYnx5whCXYythXKvp/nMWP4Dp7jwdBJZV6WdOqKUtqWkKvUqtTHl7TeC9H7obkHD7Wq/aiqTHujl9fUEeAtvzUeHuduRPGAnSYsR5ewT/nj7svjENc6062i/pMRKMw2J HOKVj/xj xA26NEeZHTlIPN4ZlXSDRaCF+UnooRfZYu7+EzNHt5riidw8iJHs3DrT13U2mgrV6nutaijFECxFM+uYduNL3ejIryFA9/4mwkKXyPTLK/i0Lm8zJYHxHfiLOYc9aMn5/kN9XZKVu9tn3mMdixQt7HfPRY8u3SEMcOW/S 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 Wed, Feb 07, 2024 at 11:12:52AM +0000, Will Deacon wrote: > 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? The pte lock cannot be taken in irq context (which I think is what you're asking?) While it is not possible to reason about all users of struct page, we are somewhat relieved of that work by noting that this is only for hugetlbfs, so we don't need to reason about slab, page tables, netmem or zsmalloc. > 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